Currently we're using Web Application project, so we have a gain with compilation. But as far as I know, the aspx pages a still compiled at the first page hit. So does precompilation give a perceptible performance gain ? (first hit exluded).
What type of web site (hits/sec, number of users) will benefit of it ?
Pre-compilation saves the first hit the work of doing the JIT compilation, for a site with a large number of pages who knows how long it will be before every page is visited and gets compilled.
After the first hit there's no difference between the page having compiled JIT or pre-compilled.
We use pre-compilation to ensure that the website will actually compile and don't get caught out by a missing reference or some issue with the production environment. This is also important so that no user has a different experience of our site because they have to wait for the JIT complilation.
Related
I have several projects in asp.net and in all of them I have the same problem. The first time I access an aspx page the load is very slow. Once I close the page and reopen it, the load is very fast. Why is the first load so slow? Can I change any settings in IIS?
Thanks
I have read a lot of documentation but I am not an expert in this and I have not gotten any progress.
By default, asp.net web pages and code files are compiled dynamically when users first request aspx page from a Web site. After pages and code files have been compiled the first time, the compiled resources are cached, so that subsequent requests to the same page are extremely efficient.
More information about asp.net dynamic compilation:
Understanding ASP.NET Dynamic Compilation.
How to: Precompile ASP.NET Web Sites for Deployment.
Ok, so several issues here.
You don't mention if you are talking about your developer computer - say hitting f5 to run the site.
next up, are you deploying a asp.net web site, or a asp.net web site application?
With a application then the compile of the code and pages occurs on YOUR computer, and the .dll's are built by Visual studio (VS). So, at deploy time, then there is a first-time delay, but it not all that long - maybe 5 seconds, and that's as app pool etc. spools up.
However, if you deploy a asp.net web site? Then unlike an "application", the source code (vb, or c#) pages for code behind are included, and deployed to the web site. And this means that IIS does the compile of pages - and often on the fly. This deployment model is often preferred by many, since you can open even the live files on the server, edit one line of code behind, hit save. On next page use, it will re-compile.
If you use an application, then as noted, IIS does not do the code compile, and in fact not even the source code is deployed during a publish. Of course, while there are many benefits to an "application", the ONE big downside is of course that you require a full site re-publish EVEN if you change just one line of code behind.
So, while an application has "some" delay for the first site use, it tends to be considerably less of a delay compared to when using/deploying a web site. (Since then, IIS has to compile the code, and in fact has to compile each page used).
You don't mention/note which deploy model and approach you are using here.
As noted, while the web site option is certainly less efforts to make a change to one page or a bit of code, I still far prefer the "application" approach, since things like "referencing" additional class library and code, and even being able to say use the Rosyln compiler (which may well not be on the server and available to IIS). As a result, I prefer and use an "application" despite the extra efforts required come publish time, but the benefits at developer time far outweigh the downsides.
And of course, one benefit of the "application" approach, is you do as a general rule get far faster web start up times.
I have a problem with an old application in asp.net.
This application runs on a server with windows server 2012 and is used by hundreds of people at the same time (same app but which is pointed to by different domains).
The problem is this: every time I modify an .asp file, the page takes a lot of time to "recompile" the code and this causes damage to the users who use it.
This problem does not occur with the exact same application but running on another dedicated server used only by one user.
I've been researching for days, the only noteworthy thing found is that, in the server iis, if I recycle on application pool -> select the application, it has exactly the same effect.
I don't know much about windows server so I ask you for help.
Thank you!
You have two types of deployment models.
First is what we call a asp.net web site,
and then second, is what we call a asp.net web site application.
They sound the same - but they are not.
So, while most perfer using a "application"? The ONE down side is that you have to re-publish the WHOLE site if you say change some code behind. This is good, and bad. The good part is that your code is re-compiled BEFORE you publish. (and in fact, you might even want to re-name "app_code", since that does re-compile by the web site.
However, for the most part a web applcation is "harder" to make a small update, since when you publish, you have to re-publish the whole site. But, the good part is that all code tends to be compiled down to ONE .dll. In effect the the site is pre-compiled before publishing. And with a applciaton, then you can add/change and do more things. In effect, the web site "applcation" allows you to do things like create say a custom logon provider. In most cases, this means the WHOLE site is under your developer control. It also means that code behind (source code) is NOT pushed up to the site.
Then you have what is called a asp.net web site. This allows you to say modify the code (code behind) of one page and then push that one page (and code) up to the site. The web site will thus re-compile that one page. You will note the "delay" that you experiance - but it ONLY occures the first time that page is published.
So, for a "application", you will in Visual Studio open up the project (and a sln file) is used.
For a web site, you from Visual Studio go open->web site.
I hands down prefer web applications, but they are MUCH harder to deploy a small change, since as noted, you have to re-publish the whole site.
However, the two different choices would thus explain the "difference" and as to why the other site don't experience the delay as much as you are. However, usually on first load - there can be a one time delay after a re-publish. And this quite much means the site is down for this time to re-publish.
Also, do keep in mind that if you do modify some files (such as web config), then this WILL cause the app-pool to re-start. (and if you not using sql server sessions, but in-memory sessions - they get blown out when you do this).
It also somewhat possible that the server with one user has more memory, more CPU and a much lighter load - so the reduced delay after making changes might well be the light load on that server.
However, the above two different publishing models and types of asp.net sites would be the first thing or at least the first issue to be aware of.
First, you need to determine if it is a website or web application project (https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1). Default for web application is rebuild for single page changes while default for website does not force recompilation except if special folders or files are modified. You may check to see if any settings for the app pool differ-- in particular "Disable Overlapping Recycle". You may also check the web.config as there may be a setting that is forcing rebuild. You want also want to look at Explicit Complication/pre-compilation option.
You may want to reference the following resources: https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/determining-what-files-need-to-be-deployed-cs
https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1
Optimization setting
https://learn.microsoft.com/en-us/archive/blogs/davidebb/a-new-flag-to-optimize-asp-net-compilation-behavior
I always prefer using a ASP.NET Web Site over ASP.NET Web Application, as defined here: ASP.NET Web Site or ASP.NET Web Application?
It is suggested that only use 'ASP.NET Web Site' projects if you really need to (stackoverflow's tag says this); I would love to move away from this type of project, but the need to debug effectively and not waste time constantly recompiling projects for trivial changes makes me regret choosing the latter every time.
This is down to two key reasons.
Whenever you make a change to a back-end file or code-file, you are forced to rebuild the project before the change is available. With the 'ASP.NET Web Site', back-end files would be available immediately, and code-files within the 'App_Code' directory would trigger an automatic background rebuild enabling changes to be available within the next request with no developer input.
Because of this constant requirement to rebuild, you cannot make a change while debugging without stopping/starting the debugger (unless you perform an attach-to-process with a few tweaks). This is very frustrating, especially when the project gets to a certain size where the compile time makes this completely impractical. Not only that you lose all your debugging states, objects which were loaded in memory have been cleared, etc.
I'm pretty sure I am missing something, as if Web Applications are the preferred project type by the majority, how can this be with such limitations? Are there solutions for this or suggestions on how to perform a series of small changes while debugging without stopping the debugger then manually performing a rebuild each time? And is there a way to prevent back end files from needing a rebuild of the whole site? (I guess this is why 'ASP.NET Web Site' has a dll for every file or directory)
It is not a limitation, it's just how it works without the on-the-fly compilation of the WebSite template.
You can use the Edit and continue feature of Visual Studio, but not every type of change is supported.
I was talking to a guy and he says he likes his site with asp but not asp.net because its 'always compiling'. I Know aspx is compiled and is separate from the main app in a dll. But what does he mean by 'always compiling'? I thought it compiles once on startup and everything you modify aspx file if you modify at all.
But anyways, how is the performance of server side ASP.NET compared to others such as php, python, ruby and java?
You're right, ASP.NET dynamically compiles ASPX web pages and caches the generated binaries when a page is hit after one of the following events:
the IIS application pool has been recycled
a change is made in the bin folder
a change is made in the Web.config file
This dynamic compilation stage comes naturally with a price in terms of page responsiveness. However it affects only the first request coming in to a specific page while it represents an performance enormous benefit for the following requests, since they are served a cached
compiled version of the page.
The performance penalty paid by the first page request can be mitigated by performing the ASP.NET compilation and caching step ahead of time. This technique is known as web site precompilation and is done through a command-line tool included in the .NET Framework called ASP.NET Compilation Tool (Aspnet_compiler.exe).
Related resources:
Understanding ASP.NET Dynamic Compilation
ASP.NET Web Site Precompilation Overview
Very generally....
The "code behind" file is compiled in advance which would generally contain most of "your" code.
The aspx itself it also compiled, but usually not in advance which is probably his reason for saying "always compiling". Each page is compiled as required and the compiled version is cached in temp files until it needs to be compiled again.
'always compiling' of asp.net is possible in some cases - if website have rare requests and application pool's idle time-out(in iis) is very short(1 minute for example). You can note that first request takes long time(about even few seconds), but after first compile it asp.net runs very fast.
speed tests - http://www.wrensoft.com/zoom/benchmarks.html
Since asp (not ASP.NET) is a script language like php everything compiles every time.
In ASP.NET you have to differentiate between presentation items (aspx pages/views) and pure code items (classes/code behind etc).
In general compilation in .NET means compiling code into IL (Intermediate Language or more generally speaking: byte code).
When such a compiled component is actually used it compiles again into actual machine code.
This process is called 'Just In Time' (JIT) compilation.
Presentation
The presentation pages are compiled the first time they are accessed. But your web server notices when they are modified and recompiles them again.
Code
Code items in fact only get compiled once. At the time you hit build in VS.
So what does that mean performance wise? Well think about it, which is further the way from user readable code to machine code or from byte code which is already close to machine code to actual machine code?
I would go with the later any day and in the past for me ASP.NET always has been proven to be faster.
Yes. The absolute first time you access a page it might take longer, but this is not the case you should think about, its the 10th and 20th visitor that you should have in mind.
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).