I have a set of reports using SSRS on a dedicated Reports server. Our reports are launched via hyper links on an aspx page. The hyper links open a report (in a new broswer) with selectable paramaters. There is no data when the reports initially load. However, the first time loading a report in the browser takes a significant amount of time. 30 - 50 seconds. Subsequent loading of any of the reports is much faster. It seemes like the server is spinning up objects in the background during the initial load.
Does anyone know the cause of this initial load performace issue?
Thanks
SSRS is just another ASP.NET app (see below) that works within the standard IIS environment.
Schedule a report email every 15 minutes to keep it loaded or change IIS settings.
SSRS comprises (from an App perspective):
A service that deals with schedules, sessions etc
ReportManager web site that looks like the main entry point to SSRS
ReportServer web service that does the work, rendering, reporz access etc
You're seeing the double whammy of ReportManager + ReportServer IIS timeouts. Scheduling will only remove the ReportServer timeout.
It's exactly what you suspect, Mike - the web server is loading all the required bits'n'pieces. You get the same delay if you try to browse to the SSRS management pages 'the first time' in a day. Once someone has opened a report, or viewed the management pages, the delay goes away.
Two things off the top of my head:
Did you test to see how long the query/sproc would execute when developing the report?
How much data are you trying to pull over? Is your data being sorted?
If you're using a query, you may want to consider using a stored procedure
Related
I'm using Sitecore instance 9.1, Solr 7.2.1, and SXA 1.8.
I have deployed the environment on Azure and while monitoring incoming requests (to CD instance), I've noticed slowness in loading some pages at specific times.
I've explored App Insights and found an unexplainable behavior the request is taking 28.7 seconds while the breakdown of it shows executions of milli-seconds .. How is that possible? and How to explain what's happening during extra 28 seconds on the app service ??
I've checked the profiler and it shows that the thread is taking only 1042.48 ms .. How is that possible ?
This is an intermittent issue happens during the day .. regular requests are being served within 3 to 4 seconds.
I noticed that Azure often shows a profile trace for a "similar", but completely different request when clicking from the End-to-end transaction view. You can check this by comparing the timestamp and URL of the profile trace and the transaction you clicked from.
For example, I see a transaction logged at 8:58:39 PM, 2021-09-25 with 9.1 s response time:
However, when I click the profile trace icon, Azure takes me to a trace that was captured 10 minutes earlier, at 08:49:20 PM, 2021-09-25 and took only 121.64 ms:
So, if the issue you experience is intermittent and you cannot replicate it easily, try looking at the profile traces with the Slowest wall clock time by going to Application Insights → Performance → Drill into profile traces:
This will show you the worst-performing requests captured by the profiler at the top of the list:
In order to figure out why it is slow, you’ll need to understand what happens internally, f.e:
How the wall clock time is spent while processing your request?
Are there any locks internally?
The source of that data is dynamic profiling, Azure can do that on demand.
The IIS stats report would show you slowest requests, so you could look into Thread Time distribution to see where those 28 seconds are spent:
In Sitecore the when the application start the Initial prefetch configuration allows to pre-populate prefetch caches. Pre-heated prefetch caches help to reduce the processing time of incoming requests. The initial prefetch configuration of caches are taking time to load on initial stage.
Sitecore XP instance takes too long to load. This is caused by a performance issue in the CatalogRepository.GetCatalogItems method. It will be fixed in upcoming updates
see Site core knowledge base
In Sitecore XP 9.0 the initial prefetch configuration was revised. The prefetch cache for the core database was configured to include items that are used to render the Sitecore Client interface.
The Sitecore Client interface is not used on Content Delivery instances. Disabling initial prefetch configuration for the Core database helps in avoiding excessive resource consumption on the SQL Server hosting the Core database.
Change the configuration of the Core database in the \App_Config\Sitecore.config file:
Refer site core knowledge base
We have a requirement to capture initial page load/paint time while callback requests are loading data on the page. We are using Load Runner performance testing. The average response times for a transaction are 9-10 seconds. However, we are more interested on how quickly the page paints vs the data in each web part is loaded (ignoring JavaScript call back requests). Is there any setting/way to capture such data in Load Runner?
If Load Runner cannot capture/distinguish the data as needed above, is there any other tool perhaps we can use with a browser by executing it manually while we are load test is going on?
Thanks !
...how quickly the page paints...
This is a GUI level event, so you will need a virtual user type which samples at the GUI to answer this issue. If you combine a GUI Virtual User (QTP-based) with a protocol level virtual user (HTTP) for a common named event (Login vs Login_GUI) then you will be able to measure the time inside of the browser.
GUI Virtual Uses have been part of the definition for LoadRunner since version 1.0. They began as XRunner defined, moved to WinRunner defined and now are defined by QuickTest Professional.
I have an MVC3 application which is working fast in my dev environment (even when pointed at the production database). However, when I publish the application and move it onto the production iis7 environment it runs at a snails pace. I understand that the inital load can take a few seconds as the application pool starts up, but this is taking 20+ seconds. Then will be fast for a few clicks and the next click will again take 20+ seconds.
I've put in the MVCMiniPorifler and it doesn't look like the database is causing problems. But, I also can't see what is causing the problem. I can hit the same page multiple times and it comes back in a second or 2 and then suddenly that same page will take 20+ seconds to respond.
Has anyone seen this sort of behaviour before? Any help would be greatly appreciated and I'm not sure what to try next.
It's possible that the other web apps running on your production server are locking required resources. Is there a common file or folder that multiple sites utilize? Are you sharing the app pool between any of the sites?
We're running 3 different Drupal (Pressflow to be specific) sites on the same server. The 2nd and 3rd sites were cloned from the first one and load just fine. The first one, though, is taking a few seconds to connect and start sending data back from the server. Same box, same config (as far as we know), same modules, and generally the same theme. Here's what Pingdom shows...
Fast site:
http://i.stack.imgur.com/YZilC.png
Slow site:
http://i.stack.imgur.com/6Um1M.png
Edit: Those are from Pingdom, the yellow indicating "The web browser is waiting for data from the server"
The configs are the same, performance options same, server configs, as far as we can tell are the same. The delay occurs before any page elements are visible so it's not an on-page object problem or a page speed problem.
Could this be a config issue with the server? Where should we be investigating?
Thanks in advance!
I would try increasing the size of your MySQL cache. It's possible the fast sites have their particular queries cached and the slow site has a query that doesn't quite fit the cache, so the MySQL query results need to be regenerated each time.
Just a guess!
I have an issue whereby SQL Server Reporting Services graph image URLs become unavailable after attempting to just request the images after a few minutes (instead of also refreshing the HTML).
The actual error is:
"The stream cannot be found. The stream identifier that is provided to an operation
cannot be located in the report server database. (rsStreamNotFound)"
Assuming the images are timing out, is there any way to extend this timeout value?
The environment is finicky and not ideal, but cannot be changed at this time. The report is being generated through an ASP.NET application (which makes a web service call and populates an ASP.NET literal control) and rendered in the "Outlook Today" page in Outlook 2000. See diagram, below:
http://paulw.us/blog/uploads/outlooktoday.GIF
The Reporting Services is running 2008, but the data comes from a SQL Server 2005 database.
There's apparently no way to do this, from what I've found. The workaround that I've implemented is to turn on caching and run a data-driven subscription to generate the report. There are some problems with this, namely that it doesn't always seem to prevent the user from having to reload the report.
A more robust way is to enable history and a batch process that changes default parameters and creates the report, cycling through everything like in a data-driven subscription, but maintaining external references to which report goes with which date and history ID. For instance, you could have a database table that tracks the report run time, report ID and parameter set, and query against it to know which to display based on your parameters.