I have a Web application (http://www.holidaystreets.com), it has around 120,000+ pages. Whenever we restart the server it takes more then 15 minutes for the site to warm up.
I built it as 'Release', do not have any heavy stuff initilizing (i.e. Control Adapters or in APPInit).
Any tips?
Mystery Solved
Well I spoted the problem today. This application was converted from WebSite type project to WebApplication type. I had codedom defined in web.config so that I can compile each page separately when requested first time. (this was done becuase we had such a huge number of pages). However in WebApplication it was compiling each and every page on first load. Since removing the section, the application is loading in less then 2 seconds!
Probably you have lots of static data that a initiated on the first hit. Look for big amount of cached data, that you use in static classes (probably getting it from the db?).
I would suggest using the System.Diagnostic.Trace class methods to log timings for various methods and events as your site is loading up for the first time to see where the time is being spent.
Also profiling your database should reveal any bottlenecks there.
I got it back in 2.65s:
http://www.webpagetest.org/test
Related
I am working on a .NET WebForms application and I have observed that whenever I build, after the build, the very first page load takes longer to load than usually. This happens even if I wait after building before I load a page. Is there a way to increase human workforce performance by changing IIS/.NET to initialize things on postbuild instead of first page load?
Yes you can, like this.
Quoting:
You can use Application Initialization Module which comes in-box with IIS 8.0, like this:
<applicationInitialization
doAppInitAfterRestart="true" >
<add initializationPage="/" />
</applicationInitialization>
This will send a request to the root of your app (initializationPage="/") every time your app starts automatically.
You can also configure the Start Mode for your application pool to Always Running which means every time IIS restarts, it will make sure to start your application pool immediately (this if from right click on your application pool then Advanced Settings).
Professional servers have hardly any latency, though it requires quite a bit of tweaking. Also, by default, applications recycle regularly on IIS (as well as when some kinds of exceptions occur, when some files are changed, or when some thresholds are reached). Professional web application hosting is anything but simple :) You might get help with that on Server Fault, perhaps.
Another option is to avoid mixing pre-compilation and JIT-compilation - if you only pre-compile, you don't need to do any compilation when the application is deployed, resulting in faster startup times. If you only deploy sources, the application domain doesn't need to be torn down when you make a change, which means that only the change needs to be recompiled, which is much faster.
And of course, ASP.NET Core is much, much faster in both scenarios - it can do the whole compilation in-memory, unlike the legacy system which uses csc to build multiple assemblies, save them to disk, load them from disk, merge them together, save that again, just to load it again and initialize.
As we trying to make more frequent builds (and as our site traffic has increased), we've noticed that during higher traffic, the initial post-build page loads spike to 20 or 30 seconds. Our builds are published by copying DLL's + PDB's to a single server which is sync'd to one other server. That file-copy generally takes a few seconds.
What are some contributing factors to this sort of initial latency spike? Are there any commonly taken steps to avoid this problem? (I can't imagine high-traffic site that perform multiple builds/day, if not multiple builds/hour, tolerate this sort of thing.)
The main cause of this delay is ASP.Net doing compilation on the pages during first load, transforming the aspx markup into code.
You can solve this (and is actually listed as the first advantage on this link) by doing a pre-compile during your build. Of course, the trade off to this is longer build times. More information is here: http://msdn.microsoft.com/en-us/library/bb398860(v=vs.100).aspx
If you're using MSBuild to handle your CI builds by using the AspNetCompiler task in MSBuild: http://msdn.microsoft.com/en-us/library/ms164291.aspx
Another advantage this has (And why I tend to use this even in development builds), is if you integrate this into your build process, and you end up with syntax errors on a page, the build will fail, instead of your users being the first one to catch it.
In response to your comment (my response was getting too long for a comment):
Actually, I wasn't even aware of the batch settings myself until now. It looks like setting batch to false makes sense during development to reduce initial load times there. But, it seems that doing so would make asp.net function in assembly-per-page mode, which can slow things down on larger apps. So, probably the best compromise would be in development environments, set batch to false to speed up development time, then use the web.config transforms to set it back to true for production, and use the pre-compiler during the production build. Then you'll only pay the pre-compilation costs once for both servers, and in a way that's not visible to users.
My main goal: make development faster by not having to wait as long each time I change the code of my site.
I'm developing an ASP.NET web application in Visual Studio 2010. While developing, I normally run the app with "Control+F5" (ie. start w/o debugging). This starts up the built-in ASP.NET Development Server. However, when I modify code and do this, I get the following:
-Press Control+F5
-The modified project(s) in my solution build
-The web-server is started (if it's not already)
-My browser opens & waits
At this point there's a 15-30 second delay before I see the first page. Reloading a page is instant, as well as modifying an .aspx page and reloading. But changing any code & recompiling causes another 15-30 second delay.
First, I'm trying to see where that time is spent (which is the point of this question). Looking at the log file, there's about 5 seconds until my global.asax.cs file runs. Then a wait of 10-15 seconds, then my Site.master.cs file runs. What is running in that time in between? What files does ASP.NET run and in what order?
Second, I can see that some of this time is spent with "csc.exe", which leads me to believe that the pages are being compiled-on-request. Can I precompile this code (again, using the built-in web server, not IIS) and will this be faster?
I'm open to other suggestions on how to make this faster. I want to minimize the time between modifying code & seeing changes on the site. There are multiple projects in this solution. One project uses the other as a reference. I'm on XP. I can use XP's IIS if that will make things faster. Any ideas?
Thnaks!
If you are curious about the internal processes and architecture of asp.net and IIS work then follow this link.. may be you will get your problem point on which you want to work.
low-level Look at the ASP.NET Architecture
and have look on this question somewhat similar to yours as Aristos comment on your question.
Slow Performance -- ASP .NET ASPNET_WP.EXE and CSC.EXE Running After Clicking Redirect Link
I need to measure the total time a page takes to fully load, from clicking a menu button to fully rendered. I did that, by using BeginRequest and EndRequest events. Because some numbers were too big, I started measuring the time for every method and event the page executed when loading. Using a stopwatch I timed Preinit, Init, Load etc, all the events in the page life cylcle plus all other methods I created. My surprise was that adding these numbers I didn't even get close to the numbers I got using begin/end request. The last one was even double, triple, eg 7 seconds comparing with the 2 seconds I got from each event/methods.
So I'm wondering, where does this extra time come from? Between my timings, which are showed in the debug window, I could see all sort of "loading jhfggdfaasdf.dll", probably some temporay file. Could this dll loading take this time?
I noticed that from time to time, my timings match, so maybe there is some cache mechanism, but I need some confirmation from someone more experienced.
EDIT: From reading your question again, you might be using the asp.net web site solution type. This is not pre compiled when you are debugging and the first time you request a page it compiles it into a class in your asp.net directory. The dll for the class is then loaded into the app domain with a funny name like the one you mentioned. This happens the first time you request one of these pages and when you want to deploy you can pre compile your site to increase performance.
If you are seeing "loading xyz.dll" it means the app domain is loading in stuff to be used by the application. This happens when you need to run code from required dlls (in your case probably third party libs) that have not yet been loaded into the app domain. This is good because it means a page that uses a library but has never been called, never loads that assembly into memory. You could move this hit from first page request to application load by pre loading all the assemblies in your bin into the app domain on application start. It is a trade off between use of memory against speed of requests. This question is a good place to start with that:
How to pre-load all deployed assemblies for an AppDomain
You can get a good overview of your page lifecycle times by using the trace functionality in asp.net. This can be set in the web.config file as described in this article:
http://msdn.microsoft.com/en-us/library/94c55d08.aspx
Viewing the trace.axd page will tell you times off the various server events and make it really easy to see where you are slow.
If the page still takes a long time to render, there are client side considerations such as
is your page very large
are you interpreting javascript before all the html and css was written
is your network slow
are you sending many css and js files? most browsers limit the number of concurrent resource downloads. maybe consider rolling a few css files into one, on your production environment at least
are you employing client cache. you can tell the browser to cache something for a period of time. there are ways to invalidate this cache if your content requires to be updated.
This can be debugged using client side tools such as firebug or the developer tools in chrome.
The stopwatch is actually a fairly cumbersome object by itself. You may actually be adding to the load time by using it to record the time. A slightly more efficient method would be to use a simple datetime comparison.
protected void Pre_Init(object sender, EventArgs e)
DateTime started = DateTime.Now;
// .... some code
lblDisplayComment.Text = DateTime.Now.Subtract(started).TotalMilliseconds.ToString();
}
This would give you the time in ms it took to execute that method only.
We've got an app written in Flex that displays data from our app. The .swf file is only 427kb, but it takes a full five seconds to load in Firefox. This is a headache for our users because they need to access the page that contains the app frequently. (The app displays documents, and it's really slow to march through a list of them).
I've confirmed that it's not a slow web server problem. The .swf appears to be cached in the browser. Firebug reports that every time the web page accesses the .swf, the app server returns a "304 Not Modified" response, meaning that the load time from the server is almost zero.
Is there anything we can do to debug this issue? Or is the Flash player just slow?
If you're having issues with the time to download the SWF or to initialize the application, you could try breaking it up into modules and using the SWFLoader to only load the pieces as you need them. Flex applications are 2-frame movies, so the more you have in your application the more there is to initialize before it can start "playing."
If it's slow rendering everything, take a look at the creationPolicy and see if you're needlessly creating a hierarchy of items that aren't being displayed. Repeaters are also notorious for rendering slowly.
If your performance problems are more in-application, then you could consider profiling your application to see where the hotspots are.
Have you tried running the app using the Flex Profiler? That may help you isolate any performance issues.
Consider checking out the Flex RSLs. These runtime shared libraries allow the Flash Player to cache the Flex framework and after the first load allow for a much faster startup time.
Look at the
creationPolicy documentation.. it may help..
The default should be "auto"... Creates all controls only in the initial view of the navigator container. This setting causes a faster startup time for the application, but results in slower response time for user navigation.
This setting is the default for multiple-view containers.
See if someone has changed your setting.