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.
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
We currently have a Live ASP.NET application (Basically a CMS) running on our IIS7 web-server.
Every once and a while (Talking every few months) it's app pool will go to 100% CPU-usage and stay there until the page times out. We've tried increasing the timeout for the page to 30 minutes in the web.config but it still just stayed at full CPU so I'm presuming it's some form of infinite loop.
It is a massive application, one of the biggest we have, and far too large to blindly search for an issue. The prevailing opinion is that since it's so rare we can just restart the app-pool whenever it happens, but I'd much prefer to fix it.
I have access to the code and full administrator access to the hosting server, and the monitoring software we're running gives me plenty of time to be on the server while the issue is taking place but I can't find any way to get useful data about what's going on at the time without adding a massive constant overhead to the site (Which given it'll take months to happen isn't really viable).
I'm wondering if anyone has some advice as to how I could narrow down our search? A stack trace of the currently running threads would be spectacular, but even just a list of the pages that are actively being served would make a huge difference. I can add code to the project to make it more traceable, but logging everything in the hopes of catching it would be unrealistic (It gets a lot of traffic and we don't want to add significant overhead to page loads).
Tess's blog is an excellent resource on debugging production asp.net applications.
I think this blog post from her blog will be really helpful in getting started in debugging this problem: Hang debugging walkthrough.
Hope this helps
I recommend you to use ASP.Net performance counter, (like the requests queue and number of requests)
I've recently deployed an ASP.NET application to my shiny new VPS and while I'm happy with the general performance increase that a VPS can give over a shared hosting solution, I'm unhappy with the startup time of my application.
My web application takes a fair amount of time to start up when my client first hits it. I'm not running it in debug mode (disabled that in my web.config), and it doesn't have any real work to do on startup - I have no code in my application start event handler, I don't start any extra threads, nothing. The first time my client hits my application it takes a good 15-20 seconds to respond. Subsequent calls take 1-2 seconds, unless I wait a few minutes for my application to shut down. Then it's back to a 15-20 second startup time.
(I'm aware that my timing benchmark is very unscientific, those numbers should just give a feel for the performance on startup of my app).
My understanding of ASP.NET was that IIS (7.0, in this case), compiles a web application the first time it is ever run, and then caches those binaries until such a time as the web application is changed. Is my understanding incorrect?
So, after that book-sized preface, here are my questions:
Is my understanding of ASP.NET's compilation incorrect? How does it actually work?
Is there a way I can force IIS to cache my binaries, or keep my application alive indefinitely?
If it's a bad idea to do either of the things in my previous question, why is it a bad idea, and what can I do instead to increase startup performance?
Thanks!
Edit: it appears my question is a slight duplicate of this question (I thought I did a better job of searching for an answer to this on here, haha). I think, however, that my question is more comprehensive, and I'd appreciate if it wasn't closed as a duplicate unless there are better, already-asked questions on here that address this.
IIS also shuts down your web app after a given time period, depending on its configuration. I'm not as familiar with IIS7 and where to configure this, so you might want to do a little research on how to configure this (starting point?).
Is it bad? Depends on how good your code is. If you're not leaking memory or resources, probably not.
The other solution is to precompile your website. This might be the better option for you. You'll have to check it out and see, however, as it may come with a downside, depending on how you interact with your website.
My understanding of ASP.NET was that IIS (7.0, in this case), compiles a web application the first time it is ever run, and then caches those binaries until such a time as the web application is changed. Is my understanding incorrect?
That is correct. Specifically, the assemblies are built as shadow copies (not to be confused with the volume snapshot service / shadow copy feature). This enables you to replace the code in the folder on the fly without affecting existing running sessions. ASP.NET will detect the change, and compile new versions into the target directory (typically Temporary ASP.NET Files). More on that process: Understanding ASP.NET Dynamic Compilation
If its purely the compilation time then often the most efficient approach is to hit the website yourself after the recycle. Make a call at regular intervals to ensure that it is you who receives the 15 second delay not your client.
I would be surprised if that is all compilation time however (depending on hardware) - do you have a lot of static instances of classes? Do they do a lot of work on start-up?
Either with tracing or profiling you could probably quite quickly work out where the start-up time was spent.
As to why keeping a process around is a bad idea, I believe its due to clear-up. No matter how well we look after our data or how well behaved the GC is, there is a good clear-up performed by restarting the process. Things like fragmentation can go away and any other resource issues that build up over time are cleared down. Therefore it is quite a bad idea to keep a server process running indefinitely.
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.
In building an ASP.NET 3.5 WAP, I'm always frustrated by the feeling that no matter how I "isolate" or "encapsulate" bits of logic or UI I'm still going to bring down the whole site any time I need to update a single line of code. I may be misunderstanding how ASP.NET handles changes in the "bin" directory, but given the number of "why is my AppDomain unloading?" messages in the various groups this still seems like something to avoid.
Does anyone have any guidance and/or frameworks to truly modularize an ASP.NET 3.5 WAP so that logic and pages can be added/updated "in flight"? I Googled System.AddIn a bit, but it seems to be focused on WPF applications.
Thanks for your help!
James White
This is really hard to achieve since .NET doesn't support unloading a type that has been loaded into the app domain.
One way to do it is playing around with app-domains, or having WCF do it for you.
Another would be implementing ayende's hod code swapping.
A third way would be putting logic in the dynamically compiled part (the ASPX). However the app will restart after a configurable amount of changes.
Use two or more servers. When you need to upgrade, take one down, upgrade it, bring it up, take the other one down, upgrade it, bring it up.
It takes a bit of effort to be able to do this - having both versions running at the same time - as database changes etc can be tricky. But the same effort also pays off in being able to roll changes back, perhaps host just a few users on an "experimental" server etc. Not to mention horizontal scaling being a good thing in general :)
You can take a different approach here, which is to make it that an AppDomain restart doesn't affect usability of the site.
To do that, move session out of process, or stop relying on session entirely.
If you do this, an appdomain restart isn't a big deal, and you are prepping your application for easier scalability across clusters if you ever get to that point.
Just an added thought, but I bet that was what that whole "COM+" bit allowed (save for shared hosts). Breaking logic down into little stateless sausage factories probably allowed for smooth fix-in-flight operations.