I am working on a large (100s of assemblies) asp.net application and during development it can take a couple of minutes for the first page to load after a recompile.
I am told that much of the delay comes from JITing the assemblies and that this delay is proportional to the number (but not the size) of assemblies. I have not yet measured this.
We are working on architectural changes to improve the situation (combine assemblies, decouple applications) but I was wondering if there are any quick hit fixes that I can get by, for example, changing IIS settings in development or combining DLLs post-build.
We are using .net 3.5.
Any suggestions for me?
Take a look into pre-compiling the apps to remove the JIT.
ngen
Precompile the assemblies you are not working on, create custom build configurations that don't build the assemblies you aren't working on, and then only the ones you need will JIT.
I worked on a project similar to yours with tons of assemblies. One strategy I employed was to only load the assemblies I needed for the development I was currently working on.
Another possibility is to merge all your assemblies with a post build action. Microsoft has this nifty tool called ILMerge. It merges multiple assemblies into one. You could write a post build script to merge these assemblies together.
You could also take this a step further by merging the assemblies you are not changing and add them as references.
Best of Luck!
sheepish
Here's a solution that I should've tried earlier: Disabling virus protection reduces the initial load time from about a minute to less than 8 seconds.
You could look at NGEN'ing your assemblies but if you are trying to speed up development time after the build then NGEN isn't really going to help you much. The time it takes to JIT your code would all be up-front with NGEN as you will have to create native instructions for everything just to test. If anything, NGEN'ing your code would be slower up front.
Related
I recently queried the former Lead Developer at my current place of employment as to why he chose to use the Razor Generator to pre-compile our views in to a separate assembly.
He made some claims below, but I can't seem to find any Razor Generator profiles and/or metrics on the web to back up the claim (10-100 times faster), and/or, if what IIS7/ASP.NET does behind the scenes regarding pre-compiled vs. runtime-compiled views and their benefit or the lack-there-of.
Can anyone point me in the right direction? Or comment?
It seems to me (as far as startup time is concerned) simply setting IIS autostart = true for the site would balance out any benefit of pre-compiling using the Razor Generator. Here is his statement:
Why are we using the Razor Generator to pre-compile our views and why put them in a separate assembly?
The first is simple, compile-time error checking. With this many views
it seemed like a great way to avoid errors on production. It's a bit
frustrating having to recompile to see the changes to the views I
admit, but it is (in my opinion) totally worth it to know that you
have that much more error checking upfront.
The second is that when the views aren't compiled in a project they
get compiled at runtime and then those compiled representations have
to be stored in ram. Sometimes, if they're not accessed regularly
(which is the case with most of those views since there are so many)
those stored compiled versions get abandoned and garbage collected to
save ram. So all but the most frequently accessed views in a site like
gaf.com end up being recompiled every time they are accessed. But if
you put them in a project the compiled versions just need to be loaded
from the dll if it's not already in memory (yes code can be garbage
collected too, but less often). Loading that from the dll is 10 - 100
times faster (that's from the Razor Generator project's site - I
didn't verify it myself, but it sounds reasonable).
We struggled with the same problem. We began compiling Views in order to catch obvious issues that would creep up on us during Integration Tests and UX Tests. Even worse were the bugs that somehow crept into production.
But, our build times became intolerable. Our developers build countless times and that became a major part of our day. We had jokes about testing after lunch so the build could be done while we were out.
We eventually moved to building before UX-tests.
Now we are moving toward pre-compiling. Only one guy on our team has adopted it for now and apparently pre-compiles are noticably better than builds (incremental vs total). And setup is basically a nuget fetch.
These articles should be a good start
http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/
http://blog.davidebbo.com/2011/06/precompile-your-mvc-views-using.html
Pre-compiling gives us all the advantages of deploying ready built binaries. Our users don't experience the momentary lag the first time a View is hit.
As far as I know IIS autostart = true will start you Application Pool but will not force compile your Views. As a result, you're left with the initial start-up hit for the first user to use each View.
I've been working on a legacy ASP.NET Web Site (versus a Web Application) project at a client for some time now, and its slow compile time has me wondering:
Are web site projects known to be slow(er) at compiling (than Web Application projects)?
It's a pretty small website, but the entire solution has tons of functionality -- 19 projects worth of it, 18 of which compile really quickly (the non-web projects). The website project itself has ~100 pages and ~15 user controls (these actually take about half of the compile time) and normally compiles within 30 to 60 seconds. A complete re-build takes closer to the latter.
So, some things I believe could be slowing it down (you debunk them):
(X)HTML validation issues (the code we inherited has thousands of compiler warnings about validation issues).
High levels of abstraction -- since the code for the website pages is compiled at run-time, I'm guessing that whatever it's doing for user controls up-front is a lengthy process so that the binding at compile-time can happen.
The mere size of the web site? I know these are not very efficient projects, and believe me, I've spent hours trying to get it converted to a web application, but Visual Studio was unable to parse a single ASPX file into its .aspx/.designer.xx components because of the validation problems I mentioned earlier.
Assuming my client won't approve more than a few hours to fix this up, is there any quick fixes, changes, or optimizations known that could help me out?
I do not have a puny computer, so its processing power is not an issue. I've also worked on Web Application projects equivalent in size and complexity that compile in just a few seconds.
I'm open to pretty much anything, so I'd love to hear your thoughts! Also, if you think this should be a wiki, let me know.
My observations have been the same: web site projects take awhile to build, longer then web app projects. I think I found some information on why, check this out: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
Search for "Iterative development". It says this about web site projects, when compared to web application projects:
By default, Visual Studio completely
compiles Web site projects whenever
you run or debug any page. This is
done to identify compile-time errors
anywhere in the site. However, a
complete site build can significantly
slow down the iterative development
process, so it is generally
recommended that you change the build
project option to compile only the
current page on run or debug.
First read this blog post Tips to optimize design-time build performance for Web Sites in Visual Studio 2005
Main points made:
Do not disable batch compilation
Leverage Server-side Compilation
Move App_Code files into a separate class library project
Check for conflicting dependencies
Turn off AutoToolboxPopulate in the Windows Forms Designer options.
Disable validation for HTML editing
Another option that could help you is switching to a RAM disk: Running development from a RAM disk – options and products
If that doesn't help maybe splitting your large WAP into multiple ones could improve compile time. Unfortunatelly that strategy requires you to drop developing on Cassini. Instead you will have to use IIS as host: Using multiple Web Application Projects (WAP) in one Solution
One fact most developers overlook in an ASP.NET Web Project is the amount of classes in the App_Code folder.
The more classes you put in it, the longer it will be the compilation time.
From the ASP.NET Compilation Overview on MSDN:
ASP.NET creates an assembly for each
application directory (such as
App_Code) and one for the main
directory. (If files in a directory
are in different programming
languages, then separate assemblies
will be created for each language.)
So, if you can basically minimize the Folder Hierarchy and reduce the amount of classes in it, it will probably reduce the compilation time.
Another thing I noticed from your post is that, you have 18 non-website projects.
I think it is a bit too excessive because think of it this way.
When the Web Project compilation starts, the ASP.NET Compiler needs to link the 18 separate DLL files.
If those projects can be combined to reduce the number of DLLs, it might help also.
From maintainability viewpoint, having 18 projects is a bit excessive unless there are REAL strong reasons to do so.
I would suggest reviewing the projects and combine them.
I hope it helps.
This may not be ideal, but you can split your projects into multiple solutions. For example you can take the user controls and put them in Solution A and the rest of projects into Solution B. Then compile the controls in Solution A and file reference to them from Solution B which should help cut down the compile time
Website or web project, the performance should be similar after compilation phase. If the issue is poor performance immediately after deploying a new set of codes, a quick way I can think of is to pre-publish the site. (see reference http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx)
Depending on the options you choose during the publishing, you may lack flexibility to make changes on the fly (which you shouldn't anyway).
I have looked through the related questions, and none of them have provided me the information I am looking for.
Currently the team I work on does deployments of individual .aspx (and .aspx.vb) files for bug fixes/enhancments. I am trying to affect change, as I really believe that deploying the "whole compiled site" is less error prone. As this is a significant change from the way things have been done, my suggestions have ben met with significant resistance.
As my google-fu has not been up to par lately, I was hoping the SO community could either tell me that I am off my rocker, and that there is nothing wrong with moving individual files, or point me to some really good resources which would allow me to make a stronger case.
Edit:
This has all been great info, and reinforces the arguments that I have already been making, can anyone argue the other side?
Deploying individual files for bug fixes and deployment is not a wise strategy. It sounds like you need a comprehensive build and deployment process. That doesn't mean it has to be complicated as there are some good tools available nowadays.
Build and deployment can get detailed, so as a minimum start try taking a look at the Microsoft Web Deployment Tool (http://www.iis.net/extensions/WebDeploymentTool). Install the tool on your build server and install it on your deployment server. Stage your ASP.NET content locally using the Visual Studio Publish command, then use the above tool to synchronize the entire package on the deployment server. I like this approach because it can be completely automated. When doing builds and deployments, aim for complete automation to reduce potential errors.
This is the bare minimum, but you will at least be certain that when specific files are changed, they are ALL synchronized on the deployment server.
Personally to me rolling back immediately is most important. Again website projects are very hard when it comes to track the changes.
you can find a good detailed comparison here. I am reproducing the article here.
1) Deployment. If you need in-place deployment, this model is perfect. However, it's not recommended since you are exposing your logic in clear text. So, anybody who have access to physical server can mess with your code and you never going to notice this. You can try to make precompiled web site, but you going to end up with a lot of dll and almost untouchable aspx files. Microsoft recognized this limitation and released Web Deployment Project tool.
2) You need to keep track of what did you change locally and what did you upload to production server. There are no versioning control. Visual Studio has Web Copy tool, but this tool fails to help. I had to build my own tool, which kept track of changes based on Visual Source Safe.
3) When you hit F5 for debug execution it takes merely 2 minutes to compile and execute whole project. Of course you can attach debugger to existing thread, but this is not an obvious solution.
4) If you ever try to generate controls on a fly you will hit first unsolvable limitation. How to reference other pages and controls. Page and control compilation happens on a per directory basis. On best case you going to get assembly for each directory, in worst each page or control is going to get its own assembly. If you need to reference another page from a control or another page you need to explicitly import it with the #Reference directive.
So for,
customControl = this.LoadControl("~/Controls/CustomUserControl.ascx") as CustomUserControl;
You need,
But what if you want to add something really dynamically and can't put all appropriate #Reference directives? Or What if you are creating server control and it doesn't have ascx file, so you don't have a place for #Reference ? Since each control has it's own assembly, it's almost impossible to do reflection.
Web Application Projects which re-appeared in Visual Studio 2005 SP1. They solves all issues mentioned above.
1) Deployment. You get just one dll per project. You can created redistributable packages and repeatable builds.You can have versioning and build scripts.
2) If you did code behind change you can upload just one dll. If you did aspx change you can upload just aspx change.
3) Execution takes 2-3 sec maximum.
4) Whole project is in one assembly, which helps reference any page or control. Conclusion. For any kind of serious work you should use Web Application Projects. Special thanks to Rick Strahl for his amazing article Compilation and Deployment in ASP.NET 2.0.
I agree with Rich.
Further information:
Deploying your SOURCE code ala the .vb files to the server is a BAD idea. Compile it. Obfuscate if you can, just don't deploy straight source. Imagine an attacker which gains access to the system. They could easily change your code and you might not ever notice. Yes, you can use a tool like reflector to decompile. But it's really hard to decompile a full site, make the changes you want, and put them back into production.
Deploying a single file might very well cause some type of problem in a related module. I'm guessing you guys don't really do QA. Tell them it's time to grow up.
Compiling your site will reduce JIT (just in time) compilation. Think performance.
I'm also going to guess that pretty much everyone has production server access. This is bad from the company's perspective as you have no controls in place. What happens when an employee decides to cause some havoc before leaving?
What you are describing is inline with Cowboy coding. Sure, it's fun to ride to the rescue but this style frequently blows everything up.
It's bad for rolling back. If you deploy as a web site vs web app, yeah you can do quick patches of one or two files, but what if you ever need to roll back to a previous version? Good luck tracking down all the files that were updated to make the new version. I much prefer the concept of a "version" for organizational reasons, and the compiled web app is much more inline with this than a "website" project.
We had this dilemma and ended up going with the compiled version mainly for the security reasons. If your site is external facing you could be compromising your security by allowing the vb files to be out there in plain text. I realize one could still get your code if they really wanted to but it would be an additional hurdle they would need to go through. If you use Visual Studio as your development environment you can publish the site pre-compiled and check the named assemblies option when publishing and this will essentially create a dll for each aspx page so you can do the one off page changes if necessary. This was a great feature we found as we were constantly updating the whole site and there were times when things would get updated that shouldn't. After using that feature we no longer had updates getting pushed that shouldn't. As far as rolling back I hope your using some type of Source control / versioning system. Team Foundation Server is great for versioning/source control but it is quite pricey.
What is the best deployment strategy depends a lot on what kind of environment you are working in, and what kind of developers you are working with.
Visual artists that started with graphic layout and worked towards programming are much more in tune to individual page generation and release. Also the .aspx.vb files are simply server side scripting, not really programming.
Programmers usually start at the command line and branch out to environments such as the web and understandably feel that good programming practices should be applied too the web, including standard test and release cycles (and compiled code).
If the site is in constant flux the individual pages would make more sense, but if you are required to deliver an installation package to your production group msi files are the way to go, since they can be easily backed out if necessary.
If you evaluate what your groups needs are, which includes the varied experience of everyone in your group, you should be able to convince either yourself or the group. This is not a matter of which is better, but which provides the best business model.
We're developing web applications using DotNetNuke as a framework and our custom modules for required functionality. The problem is, that it takes a long time for the website to load when you do any changes to code. I'm looking at up to 1 minute for each restart, which really is painfully slow. This leads to very slow develop-rebuild-test cycle.
We're using both console projects and winforms projects as testing ground for new functionality for faster development, but still there is lots of UI functionality that has to be done with a browser.
Does anyone have any tips on how to speed up/prevent the appdomain restart that occurs when something changes in the bin folder of a web app?
DNN does a compile on demand when you add/change pages, if you pre-compile them your turn around time should be much faster.
You're bumping up against a drawback of ASP.NET, when used with large web apps.
DotNetNuke has many significant DLLs and VB files that will all have to be reprocessed if all you do is change one single DLL. If you have 50 Module DLL's in your bin, all 50 Module DLL's will be reprocessed by ASP.Net upon your next application request.
Here is my suggestion:
Hook up the following folders to your source control (not your entire DNN folder):
bin (I suggest ignoring all DNN DLL's, so upgrades go smoother)
Portals_default\Skins
Portals_default\Containers
js
DesktopModules (ignore Admin or any built in modules)
images (ignore the core DNN images if you wish, or any of your own clunky images folders like thousands of customer photos)
(optional) CompanyName\ (where you might wish to keep other .NET Projects that need relative access to DLL's in the bin folder)
When one of your developers requires repetitive compiles / page loads, he will benefit most by eliminating as many DLL's in the bin folder as possible. It will also help to use a barebones skin for testing, if you can (They are very easy to make).
The barebones skin (which should utilize 1 or 2 skin objects, at most) and an absolute minimum of DLL's (DNN Core + the bare minimum of your own) will get you the best speed for development.
When your developer is done with the focused development of the one module, he can update those folders which he deleted items from source control (svn here), finish testing his code in the context of the full DLL/Skin set, and he'll be set.
Sometimes it is worth the trouble. I can't get you down to a few seconds of ASP.NET reprocessing, but I can get you down to 10-15 seconds. (assuming you're running on an SSD)
As far as production restarts, make sure your APP Pool recycles during off-hours.
I've looked into whether multi-core setups can somehow decrease this reprocessing time, but haven't had any luck (I have an open question on serverfault)
Maybe this would help you?
Speeding up build times in ASP.NET
What's the performance penalty on defining classes in an aspx/ascx codebehind rather than compiling them into a dll beforehand? I know that this isn't a best practice and that there are numerous problems with this (e.g. difficult to unit test, code is not reusable, etc.), but it does come in very handy when you're dealing with classes that need to be modified on the fly several times a day since those modifications will not require any sort of app restart (e.g. App_Code changes, updating dlls in bin folder).
"None." The codebehind classes are compiled into a DLL on the fly, and then that DLL is kept around. So basically the first time you load the page there will be a short delay, but afterwards the speed should be the same as with precompiled classes.
You should see no performance issue after the initial compile. It sounds as though you have business logic that is changing frequently, and not necessarily the web pages.
The choice of whether to use dynamic compilation or compiled DLLs really has to do with how organized your release process is. If your application is tightly compiled into DLLs than you can expect that you've tested for build errors and expect things to be more sturdy when you release. With dynamic compilation you have the ability to swap out .cs files on the fly (e.g. drag & drop, ftp). This means you may be more agile, but you might not have that extra step of assurance that helps you know you're keeping the build intact.
Collateral damage - session resets
From personal experience, users are much more likely to complain about session reset caused by App Domain recycling than about slight performance hit. So if you can shift your changes from code to data and avoid code updates altogether, by all means do it. This will improve your users' performance :)
I don't believe there really is a performance penalty after the initial dynamic compilation (which will occur on the first hit to the page whose code-behind was modified). How did you end up having to change classes several times a day? That would suck!
EDIT:
I should've added that this shouldn't affect unit tests or the code-reusability like you stated. There's nothing stopping you from deploying a non-pre-compiled site for maintainability purposes while still being able to run unit tests, deploying compiled assemblies for other projects (if needed), etc. during a check-in/build.
However, if you're not using source control and don't have an automated build, then there's a whole new problem. Our team members used to edit CODE files directly on production servers. shivers