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.
Related
I have some major performance issues regarding my ASP.NET web application. Navigation between pages etc. is fine, but the initial startup (in any mode) takes up to several minutes. Visual Studio seems to be busy loading symbols in this long period of time - especially temporary asp.net files... I've tried several different supposed solutions that I've found on Google; like caching the symbols, enabling just my code, deleting all breakpoints, deleting the Temporary ASP.NET Files folder and most of the tips on this site:
http://blog.lavablast.com/post/2010/12/01/Slash-your-ASPNET-compileload-time.aspx
and this:
https://blogs.msdn.microsoft.com/visualstudioalm/2015/03/03/make-debugging-faster-with-visual-studio/
, but without any luck - not even a slight performance improvement.
I don't really know how to troubleshoot it properly, so feel free to ask me to try something - I'm spending almost en hour every day waiting for my application to start, so I'm ready to try anything. I'm using Visual Studio 2012.
EDIT: I looks like it loads the symbols for the Temporary ASP.NET Files every time, instead of using the ones already there, and there is SO many files that it makes sense that it takes a while to load them all... Is there a way to stop it from loading them all from the beginning on every single startup?
For me the best solution for slow first load after some modifications made was to set this in web.config of my developer machine:
<compilation batch="false"></compilation>
When an ASP.NET website is loaded for the first time, it pre-compiles
all your pages and user controls. Once done, everything runs faster.
This is great for production websites, but horrible for your
development machine. Why? When programming, you’re usually only
modifying a page or two (or back-end code). You’ll iteratively make a
change, compile, launch the website, test, and start over; often
dozens of times. A two minute compile/load time (like we had) forces
you to lose focus and get distracted. The following setting makes
pre-compilation more selective, making the first load time massively
faster in development scenarios. On my machine, it cut the first load
time from around 74 seconds to 6 seconds.
You can check other performance tips here: http://blog.lavablast.com/post/2010/12/01/Slash-your-ASPNET-compileload-time.aspx
Having recently started doing more web development I've come across both:
Web Applications
Web Sites
From my understanding a Web application all gets compiled into the binaries and run. While a Web site essentially lazy compiles pages upon requests. Working with websites seems a lot nicer especially when dealing with a massive project (in my case Kentico CMS) because you don't need to worry about long build times and IIS recycles.
However what I don't understand is how you effectively protect against errors early on? It feels like the mode has switched from build errors, to runtime errors. So if I refactor a method signature by adding a new parameter for example how do I effectively ensure that I've not broken any calls (without using a Find all references / using external tooling)?
You will want to look at test driven development if you are wanting to be sure that you are keeping errors out of your project.
If you do a web application yes it gets compiled and that is actually a bit faster even though load times can be longer. A web site is compiled as called and can be a bit slower. There is no reason you can't combine the two like I do.
Usually I do the presentation layer as a web site and then all the logic and data is all contained in dlls - gives a sort of the best of both worlds effect. I can make small tweaks to my display pages without having to recompile (or if i have two users of the same application they can have totally different layouts) but the data layer and logic are all encapsulated and safe. Those pieces can be tested away from the site and if you really get ambitious then you could work in Continuous Integration to automatically deploy builds if they pass all the tests.
Lots of options.
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.
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