I've gotten thrown into a WebForms ASP.NET 3.5 project on VS2008. The solution has 5 projects, so not too large. One thing that really annoys me is how long it takes go to from F5 to an actual web page that I can do something about (good 15-20 seconds). The box I am on is relatively recent - everything else on it feels really snappy.
What are some of the things I can do to speed up this process?
If you don't need to debug, don't do it. What I do is start the project without debugging (ctrl + F5). you've now got a window attached to VS. All you need to do now is rebuild your code when you make code changes, which is much quicker.
Simon
Directly reference the dlls instead of the projects.(If the referenced projects are compiled in release mode that's better)
Set optimizeCompilations=”true” :
When you experience very slow performance on
an initial request to an ASP.NET Web site after you change the
App_Code folder, the bin folder, or the Global.asax file.Turning on this flag will improve the performance.
Use Combress (http://combres.codeplex.com/) to minify css and javascript files.
Enable Gzip compression to reduce the network traffic on the network.This may reduce the network traffic by more than 50%.
http://developer.yahoo.com/performance/rules.html.
try to implement the best coding practices.
These things will definitely improve the performance of the site.
Related
We have an ASP.Net Webforms site (.Net 3.5) that has about 100 references in the project, so it's not tiny. Reuilding the site takes maybe 20-30 seconds but it's the load time that's a killer. At least 5 minutes before the first page opens in the browser on our development machines. We're building in VS 2012 fwiw.
What can we do to speed things up? There's an 'optimizeCompilation' flag you can put into web.config, and that's helped a little but not as much as we'd hoped. Is there a checklist we can go through to try and find the real bottlenecks in the site load time?
I can state that when the site is coming up the ASP.Net Temporary files folder slowly accumulates files. When all is said and done there are about 2500 files in there, ~70MB total size. It almost feels like we can hand-write the contents of that folder using Notepad faster than ASP.Net puts them in there.
What difference do you get if you change from Debug to Release ?
Also, have a look at native image generation:
Does it help to use NGEN?
Lastly, 100 references seems excessive! What are you doing with them? Is it your own code? Can you consolidate your own code into single projects ?
Do some of these references themselves reference web services or anything like that ?
I have tried looking at "related" questions for answers to this but they don't seem to actually be related...
Basically I have a VB.Net application with a catalogue, administration section (which can alter the catalogue, monitor page views etc etc) and other basic pages on the customer front end.
When I compile and run the app on my local machine it seems to compile fairly quickly and run very fast. However when deployed on the server it seems to take forever and a day on the very first page load (no matter what page it is, how many stylesheets / JS files there are, how many images there are, how big the page markup is and so on). After this ALL the pages load really fast. My guess is this is due to having to load the code from scratch; after that, until it is recycled, the application runs perfectly fast. Does anyone have any idea how I could speed this part of the application up? I am afraid that some customers (on slow connections such as my own at less than dial-up speed) may be leaving the site never to return as a result of it not loading fast enough. Any help would be greatly appreciated.
Thanks in advance.
Regards,
Richard
PS If you refer to some of my other questions you will find out a bit more about the system, such as the fact that most of the data is loaded into objects on the first page load - I am slowly sorting this out but it does not appear to be making all that much of a difference. I have considered using Linq-to-SQL instead but that, as far as I know, does not give me too much flexibility. I would rather define my own system architecture and make it specific to the company, rather than working within the restrictions of Linq-to-SQL.
If you can, the quickest easiest solution is simply to configure the AppDomain not to recycle after a period of inactivity. How this is accomplished differs between IIS 6 & IIS 7.
Another option is to write a small utility program that requests a page from your site every 4 minutes and set it up as a scheduled task on another PC that is on all the time. That at least will prevent the timeout and consequent AppDomain recycle from happening. It is a hack, to be sure, but sometimes any solution is better than none.
The proper solution, however, is to precompile your views. How exactly to accomplish and deploy that will depend on the exact type of Visual Studio project your web site is.
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 been programming in php for a while, and recently I started a new job ago where I am now programming in c#/asp.net.
While asp has decent performance when deployed, there is one thing that has been bugging me for the past few months. After any code change it takes about 30 seconds for the page to reload for testing.
I guess it is doing the JIT compiling or something. But it can be REALLY frustrating, especially if I am concentrating, and want to test out several incremental changes as quickly as possible, only to have to stare at a blank page for 30 seconds.
Does anyone have any tips to speed this process up?
In Visual studio 2005 every reference you add adds a .refresh file that makes sure the reference did not change since last time and if so brings the new version - if your references stay the same, you can just remove it!
also see here for more tips for VS 2005
Two things I have found:
Try alternating between the "User Visual Studio Development Server" and "Local IIS Server" in your project properties / Web tab. Depending on your project, one may be faster to start and attach to than the other.
If you have projects in your solution, such as CLR-based SQL procedures, they take a few seconds to deploy to the SQL server. If you can afford to remember to turn them back on, or make a separate project config, disable them in the build so they do not get deployed every time you press F5.
Doing those cut my "F5 to live" time from about 20 seconds to 4.
I guess that can be frustrating coming from PHP.
Thirty seconds sounds far too long though. Ensure the basics like free ram etc..
A couple of tips.
1. You do not have to run the debugger in order to run the site. Once you have the site up with the built in VS web server or IIS, you can make your code changes, build and just refresh the page in your browser. No need to hit play and have VS start the whole debug process. If you actually want to debug though, you don't have a choice.
2. Changes to an aspx page do not require a rebuild. I make changes and simply refresh the page to see the result instantly.
Check out the web tab in the project settings to configure how you want VS to handle serving the site. There are some options in there to hopefully help you suite it to your style. ex. I don't let VS launch a browser for me whenever I want to debug. I set the option for it to just wait for a request. Then I can just use the browser of my choice to get started.
Good luck
I feel your pain.
Personnaly I like the ASP.NET website project better for speed of developing.
I don't know if you have that possibility though..
In visual studio do file->new website.
For this project type you don't need a rebuild all the time and you can just refresh a page in your browser when you have changed it. (no rebuild/debug necessary)
I've had similar experiences, it can be slow to recompile at times, but varies based on where and what code is being changed - ie if it is app_code or just page specific.
What sort of hardware are you running on? VS can be a memory hog, and anything less than 2GB seems to make it slow.
Our website has a very long load time due to actions which only occur during the Application Start phase (when the ASP worker process starts). In particular loading commonly used objects from a database into memory was causing a significant delay. We found that using compilation symbols to disable some features when debugging eg security and user roles, helped a lot.
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