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.
Related
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
What is the best way to add into the build/compile script of an Asp.net project to initiate a IIS to restart the website on DLL rebuild instead of the first request to the site.
Current Process
Compile Project
Wait
Hit APSX Page
IIS starts reload
Wait
Page loads
Ideal process:
Compile Project & Reload IIS
Wait
Hit APSX Page
Page loads
The first way I though of was add a request to just hit one of the pages in the "Post-Build events". Just wondering best practices. This would be similar to "Start" which opens a page immediately on build.
Update:
The reason I would like to accomplish this is for just for efficiency. I would the to encapsulate the compile time and the restart time into one batch to save on time on step 4 below
VS: ctrl+shift+b
Wait for visual que "Build succeeded".
Broswer: F5.
Wait for IIS reload. (as well as Hit kbd>F5 in unanswered questions in SO)
Test page
Add ‘iisreset /stop’ into the Pre-Build event and ‘iisreset /restart’ at the end of the Post-Build event.
As David mentioned, you should try to find out what the underlying issue is here. If you are experiencing performance issues when first loading a website, this is quite normal. The initial compilation often takes some time to occur. Resetting IIS is only going to make it take longer. If there is another issue, please post your reason for doing this here, and we can see if we can help you.
A naive way would be to write a shell vb script or PowerShell script to use XmlHttpRequest to request a page from the site, and include that as a post-build task.
Is there any particular reason you feel the need to do this? If you're experiencing performance issues at the first JIT then you may need to consider breaking up your application into smaller projects/DLLs (assuming that size is the issue), or start looking at bottlenecks that occur when your app starts.
Another question: why the IIS reset? That won't cause the DLL to be recompiled until the first page request. Unlike classic ASP, it isn't necessary to restart IIS for DLL changes to be allowed/take effect.
The "wait" you are hoping to remove from the process is most likely the aspx markup pages compiling. When you build in VS by default it will compile all your code, but it will not compile your markup aspx pages. You can get round this by adding a Web Deployment Project to your solution, which allows you to precompile the markup pages. This way the initial load time after deployment should not be very much different to any other load time.
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.
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
I have deployed an application written in ASP.NET 2.0 into production and it's experiencing some latency issues. Pages are taking about 4-5 seconds to load. GridView refreshing are taking around the same time to load.
The app runs fine on the develpment box. I did the following investigation on the server
Checked the available memory ... 80% used.
Cheched the processor ... 1%
Checked disk IO from perfmon, less than 15%
The server config is
Windows Server 2003 Sp2
Dual 2.0 GZH
2GB RAM
Running SQL Server 2005 and IIS only
Is there anything else I can troubleshoot? I also checked the event log for errors, it's clean.
EDITED ~ The only difference I just picked up is on the DEV box I am using IE7 and the clients are using IE6 - Could this be an issue?
UPDATE ~ I updated all clients to IE8 and noticed a 30% increase in the performance. I finally found out I left my debug=true in the web.config file. Setting that to flase got the app back to the stable performance... I still can't believe I did that.
First thing I would do is enable tracing. (see: https://web.archive.org/web/20210324184141/http://www.4guysfromrolla.com/webtech/081501-1.shtml)
then add tracing points to your page generation code to give you an idea of how long each part of the page build takes:
System.Diagnostics.Trace.Write(
"Starting Page init",
"TraceCheck");
//Init page
System.Diagnostics.Trace.Write(
"End Page init",
"TraceCheck");
System.Diagnostics.Trace.Write(
"Starting Data Fetch",
"TraceCheck");
//Get Data
System.Diagnostics.Trace.Write(
"End Data Fetch",
"TraceCheck");
etc
this way you can see exactly how long each stage is taking and then target that area.
Double check that you application is not running in debug mode. In your web.config file check that the debug attribute under system.web\compilation is set to false.
Besides making the application run slower and using more system memory you will also experience slow page loading since noting is cached when in debug mode.
Also check your page size. A developer friend of mine once loaded an entire table into viewstate. A 12 megabyte page will slip by when developing on your local machine, but becomes immediately noticeable in production.
Are you running against the same SQL Server as in your tests or a different one?
In order to find out where the time's coming from you could add some trace statements to your page load, and then load the page with tracing turned on. That might help point to the problem.
Also, what are the specs of your development box? The same?
Depending on the version of visual studio you have, Team Developer has a Performance Wizard you might want to investigate.
Also, if you use IE 8, it has a Profiler which will let you see how long the site takes to load in the browser itself. One of the first things to determine is whether the time is client side or server side.
If client side, start looking at what javascript you have and optimize / get rid of it.
If server side, you need to look at all of the performance counters (perfmon). For example, we had an app that crawled on the production servers due to a tremendous amount of JIT going on.
You also need to look at the communication between the web and database server. How long are queries taking? Are the boxes thrashing the disk drives? etc.