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
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.
I'm working on a fairly large ASP.NET web application and I'm taking a big productivity hit when I do work in the interface. I can zip through adding features to the database and API, then I hit the interface and having to recompile and run eats up a lot of my day.
For example if i'm working on a tricky bit that isn't behaving quite right and requires a number of tweaks I'll have to go through multiple [stop/tweak/build/run/log in/navigate back to page] cycles, which really kills my flow and has me staring at the screen with my finger hovering over the hackernews bookmark each time.
I've been fiddling with ways to get around this problem but I haven't improved my situation much. Here's what I've found so far:
visual studio will restart the app frequently when you change static files (js/css/etc), which shouldn't require a restart. If you run VS with IIS express instead this problem goes away.
If I know I have a bunch of messing around to do i'll cut/paste my code into a server script tag on the markup page, run the product, and tweak until it's good, then cut/paste it back. This is annoying because it often requires setting up a number of Imports page declarations and code editing features in ASP.NET files, while better than ever in VS2010, is not as good as in C# files. Plus, it still restarts the app occasionally once enough changes are made.
I can exclude the codebehind file from the web application project, change the "codebehind" attribute in the aspx page declaration to an "src" attribute, then edit the code from there while the app runs (until i make enough changes to trigger a restart.) However now intellisense doesn't work in the codebehind, among other things.
Am I missing something blindingly obvious here, or is development in ASP.NET web applications really supposed to be this slow? Thanks for any solutions you can offer.
I never run my applications through Visual Studio. Set yourself up with IIS and then configure a site to point to the location of your application along with a faux domain. Edit your hosts file to point the domain to localhost.
Then when you want to view your site, just visit the domain that you chose. If you need to modify CSS or script, just make your changes and refresh the page. If you make a code change, compile your app and then refresh the page.
If you need to actually use the Visual Studio debugger, then just attach to the IIS process (application pool name) and your breakpoints will get hit.
I've found a combination of techniques that brings my productivity up a fair bit.
Use an alternative browser like Chrome. When you stop the VS debugger and you're using IE, VS will shut down the browser, but it won't do it with Chrome (or Firefox, or anything else.)
Switched web.config to run in Windows Authentication mode and wrote a quick transparent login routine enclosed in conditional compilation tags (debug only, this feature is not perfect for our production product.)
Now when I'm getting into it I can stop the debugger (which no longer closes the browser,) make code changes, build, optionally start the debugger again, and just hit F5 in Chrome to load the latest. The refresh obviously takes longer since the app has to start up but there's no "run browser/log in/navigate back to the page" task anymore.
Hopefully this will help somebody else in a similar situation.
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.
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.
During our build process we run aspnet_compiler.exe against our websites to make sure that all the late-bound stuff in ASP.NET/MVC actually builds (I know nothing about ASP.NET but am assured this is necessary to prevent finding the failures at runtime).
Our sites are fairly large in size, with a few hundred pages/views/controls/etc. however the time taken seems excessive in the 10-15 minute range (for reference, this is longer than it takes the entire solution with approx 40 projects to compile, and we're only pre-compiling two website projects).
I doubt that hardware is the issue as I'm running on the latest Quad core Intel chip, with 4GB RAM and a WD Velociraptor 10,000rpm hard disk. And part of what's odd is that the EXE doesn't seem to be using much CPU (1-5%) and doesn't seem to be doing an awful lot of I/O either.
So... is this a known issue? Why is it so slow? And is there any way to speed it up?
Note: To clarify a couple of things people have answered about, I am not talking about the compilation of code within Visual Studio. We're using web application projects already, and the speed of compilation of those is not the issue. The problem is the pre-compilation of the site after these projects have already been compiled (see this MSDN page for more details) as part of the dev build script. We are performing in-place pre-compilation, not copying the files to a target directory.
Switching to Roslyn compiler most likely will significantly improve precompile time. Here is a good article about it: https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/.
In addition to this, make sure that batch compilation is enabled by setting batch attribute to true on the compilation element.
Simply, the aspnet_compiler uses what is effectively a "global compiler lock" whenever it starts pre-compiling any individual aspx page; it is basically only allowed to compile each page sequentially.
There are reasons for this (although I personally disagree with them) - primarily, in order to detect and prevent circular references causing an infinite loop of sorts, as well as ensuring that all dependencies are properly built before the requiring page is compiled, they avoid a lot of "nasty CS issues".
I once started writing a massively-forked version of aspnet_compiler.exe last time I worked at a web company, but got tied up with "real work" and never finished it. Biggest problem is the ASPX pages: the MVC/Razor stuff you can parallelize the HELL out of, but the ASPX parse/compile engine is about 20 levels deep of internal and private classes/methods.
Compiler should generate second code-behind file for every .aspx page, check
During compilation, aspnet_compiler.exe will copy ALL of the web site files to the output directory, including css, js and images.
You'll get better compilation times using Web application project instead of Web site model.
I don't have any specific hot tips for this compiler, but when I have this sort of problem, I run ProcMon to see what the process is doing on the machine, and I run Wireshark to check that it isn't spending ages timing-out some network access to a long-forgotten machine which is referenced in some registry key or environment variable.
Just my 2 cents.
One of the things slowing down ASP.NET views precompilation significantly is the -fixednames command line option for aspnet_compiler.exe. Do not use it especially if you're on Razor/MVC.
When publishing the wep app from Visual Studio make sure you select "Do not merge", and do not select "create separate assembly" cause this is what causes the global lock and slows things down.
More info here https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx