In development, our Asp.Net 4 website takes a fairly lengthy time to start after the project libraries are built
We do a fair amount of population of statics etc, but not enough to justify the length of time it takes the app to come up (probably 3-4 minutes)
We aren't building the website, just the libraries, and batch != true in the compilation element in the .config file.
I will try log some diagnostics, but any other pointers would be useful
You can also try the optimizeCompilations="true", on the compilation session of web.config.
<compilation debug="true" batch="false" optimizeCompilations="true" >
My site also makes too long to run for the fist time, after I compile my dll's.
Hope the below steps will reduce your time
Close your project then delete the 'Visual Studio Solution User Options (.suo)' file and reopen the project
if you have a lot of projects linked to the solution, when you do a build it will build EVERY project. if you have projects that you aren't making changes to, it is acceptable to remove the project itself and reference directly to the .dll.
The right thing to do here is to use either dotTrace or Dynatrace to profile and understand what is the problem. It will tell you how long it takes to execute all your code.
Another potential issue is that your solution is not finding the appropriate libraries. Turn on fusion log viewer to determine if there are any assembly binding failures.
Related
So, I have an asp.net mvc app that is being worked on by multiple developers in differing capacities. This is our first time working on a mvc app and my first time working with .NET. Our app does not have a lot of unit tests in it...
The problem we are having is trying to keep each other from overwriting each others changes. For example:
Two developers are both working on the app and Jon (not his real name) makes a change to a controller, compiles a new dll, and checks in his stuff (both the controller and the dll.) Our svn system automatically updates our DEV server with the changes that Jon just made.
Clyde (also not a real name) also makes a change right about the same time but did not update the code with Jon's change and commits a new dll thereby "forgetting" about Jon's change.
This happens a lot. The question I'm asking is more of a workflow question - how do we solve this issue? Is it just a matter of Clyde needing to be more careful? Can anybody recommend a decent process for us to use?
You don't check in the DLL's. Exclude the bin folder from Subversion in its entirety. It's the .cs files that matter and that will be compiled locally on every computer that checks out the code from Subversion. If your deployment script don't compile the code but is just a simple xcopy statement, you need to either introduce csc to the script or implement a continuous integration system like TeamCity.
The issue you describe is already handled by subversion. When Clyde tries to commit his changes subversion will detect the conflict and offer him the possibility to merge his changes.
This is exactly the scenario that Subversion and other version control systems are designed to avoid. When Clyde checks in, he should get an "out-of-date" error and his commit should fail, thereby forcing him to update his working copy and get Jon's changes before he can commit his own.
Check out the SVN video tutorials from dime casts. These show you best practices like how to setup your project, and how to do the "check in dance" which will avoid the situation you ran into/
http://www.dimecasts.net/Casts/ByTag/SVN
I've used Subersion and .NET application together. Basically what we learned was that you should always do an update to your working copy before making a checkin. That way, any changes made by other developers will be brought down to your working copy and any merge conflicts will be quickly known to you. You can then fix the merge conflicts, checkin and continue to work. If your second developer then updates their working code, the first developers merged code will be brought down and the process will be repeated.
Hope this helps.
ignore the folders bin and obj, but we have bin and Bin.
use svn:ignore
[bB]in
[oO]bj
*.suo
How useful is it to use Aspnet_compiler.exe instead of conventional Publish via Visual Studio? And what about resource (resx) files?
Precompilation, as opposed to simple xcopy gives you two main advantages:
The filesystem will not have all the code in .aspx files and all the code behind is compiled into an assembly.
There is no ASP.NET compilation delay the first time you visit a page after the server starts up.
Having said that, my precompilation knowledge is a bit rusty these days, last time I touched it was a while back.
By pre compiling the site your server won't have to compile the site on the first visit. You have probably noticed that the first time you view an asp.net page there is a noticeable delay.
In addition you don't have to ship all your files since the code is already compiled. This can be useful if you don't trust whoever is hosting your pages.
Visual Studio's "Publish" feature is actually just a nice frontend to aspnet_compiler.exe. Publish has the advantage of being very easy to execute, where aspnet_compiler.exe requires some tweaking to get the results you're after.
I have an ASP.NET 2.0 application (installed on IIS 6.0 from an MSI) which was compiled as a "web site", and precompiled/packaged using a web deployment project, in Visual Studio 2005. (I have put in a request to the developers to consider changing to a web application for the next version, but it won't change for this version).
Whenever the application is recycled (e.g. a change is made to the web.config), on first hit, ASP.NET JITs the application. As part of this, it takes all the assemblies required for the login page and compiles them into native code in the Temporary ASP.NET Files 'assembly\dl3' directory, which takes between 20 and 60 seconds. This only happens on a recycle, which happens infrequently — but when it does, it causes the page to take much longer to load, and I believe it may be possible to optimize this.
There appear to be 122 DLLs that it needs to consider, some of which are the precompiled code-behind, others are third party components for the web site (for example, NHibernate.dll, reporting components, etc.)
Why does it recompile/re-JIT everything? Why does it not detect that most of the assemblies have not changed, and not attempt to change them? Can I prove it's not batch compilation that is causing the problem? (I have <compilation debug="false"> set in the web.config.)
Other questions suggest NGEN might be useful but I read it's not possible to use it on ASP.NET 1.x; we are using 2.0 and I can't find a clean answer either way.
From my personal experience slow recycle is often caused by NHibernate/ActiveRecord if you have lots of entities. See http://nhibernate.info/blog/2009/03/13/an-improvement-on-sessionfactory-initialization.html for explanation + possible solution.
Are you running IIS? I'm fairly certain that if you restart your site in IIS it will pick up any changes to configs without copying the dlls.
You may be able to improve your recycle time by installing common DLLs that change infrequently -- such as NHibernate or reporting tools -- into the GAC. That should prevent them from being re-jitted.
How to: Install an Assembly into the Global Assembly Cache
It's strange that only copying the dll takes 20 seconds. I would suggest to do another check and make sure where the bottleneck is.
How can you be certain that everything is in the proper state without recycling/resetting (or whatever happens) the AppDomain? Imaging that you have something in application start (global.asax) which sets the value of a static field based on a config value. Unless you reset the entire AppDomain you cannot be sure.
Another reason: There is no way to unload a .NET dll once its loaded, so you have to recreate the app domain when something is updated.
We have a couple of large solutions, each with about 40 individual projects (class libraries and nested websites). It takes about 2 minutes to do a full rebuild all.
A couple of specs on the system:
Visual Studio 2005, C#
Primary project is a Web Application Project
40 projects in total (4 Web projects)
We use the internal VS webserver
We extensively use user controls, right down to a user control which contains a textbox
We have a couple of inline web projects that allows us to do partial deployment
About 120 user controls
About 200.000 lines of code (incl. HTML)
We use Source Safe
What I would like to know is how to bring down the time it takes when hitting the site with a browser for the first time. And, I'm not talking about post full deployment - I'm talking about doing a small change in the code, build, refresh browser.
This first hit, takes about 1 minute 15 seconds before data gets back.
To speed things up, I have experimented a little with Ram disks, specifically changing the <compilation> attribute in web.config, setting the tempDirectory to my Ram disk.
This does speed things up a bit. Interestingly though, this totally removed ALL IO access during first hit from the browser.
Remarks
We never do a full compile during development, only partial. For example, the class library being worked on is compiled and then the main site is compiled which then copies the binaries from the class library to the bin directory.
I understand that the asp.net engine needs to parse all the ascx/aspx files after critical files have been changed (bin dir for example) but, what I don't understand is why it needs to do that when only one library dll has been modified.
So, anybody know of a way to either:
Sub segment the solutions to provide faster first hit or fine tune settings in config files or something.
And, again: I'm only talking about development, NOT production deployment, so doing the pre-built compile option is not applicable.
Thanks, Ruvan
Wow, 120 user controls, some of which only contain a single TextBox? This sounds like a lot of code.
When you change a library project, all projects that depend on that library project then need to be recompiled, and also every project that depends on them, etc, all the way up the stack. You know you've only made a 1 line change to a function which doesn't affect all of your user controls, but the compiler doesn't know that.
And as you're probably aware ASPX and ASCX files are only compiled when the web application is first hit.
A possible speed omprovement might be gained by changing your ASCX files into Composite Controls instead, inside another Library Project. These would then be compiled at compile time (if you will) rather than at web application load time.
The first time I load the website in the production web server, it start very slow, subsequent pages load very quickly (included the home page).
I precompiled the site, but nothing changes.
I don't have any code at Application start.
I don't have cached items.
Any ideas? How can I find out what is happening?
It's just your app domain loading up and loading any binaries into memory. Also, it's initializing static variables, so if you have a static variable that loads up a lot of data from the db, it might take a bit.
When you published the site, did you choose to make the website "updatable" in the publish website's settings or not? If I remember well, the aspx / ascx file need to be compiled as well, and if they are "updatable" then the first start will cause a recompile of those resources.
Have you turned on tracing in your web.config?
Try clearing your event log?
use http://www.iis.net/expand/ApplicationWarmUp for warming up your app
this is for IIS 7.5 - so if you are running on Server R2 then it will work.
Make sure you publish your application in 'release' and not 'debug'. I've noticed this decreases loading time considerably. The web.config file will be updated.
This sounds very much like background compiling; though if you're precompiling, that shouldn't be an issue.
First thing I would look at is your ORM (if any). NHibernate, in particular, has a serious startup penalty, as it runs multiple compilers in the background at startup to turn each class in your data layer into its own in-memory assembly.
Just a quick nod at Darren. That's typical behavior of a .NET app after a DLL update is made. After the initial load everything should zip along just fine.
When you say "precompile" the site, are you using the aspnet_compiler utility to precompile, or simply using the "Build site" option in Visual Studio?
If you are not carrying out the former, I recommend giving it a spin. Coupled with Web Deployment Projects, you should have an easier time deploying your site for each release.
The initial slowness is a couple things:
The appDomain is being setup
ASP.NET is parsing and compiling the ASPX pages.
Global Contexts are being initialized.
This is normal behavior for ASP.NET.
#Mickey: No, it is turned off. Do I need to turn it on to find out?
The trace log will show you how long each action takes. It could help you find what is taking so long.
Here is a link that might help you get it setup.