The response times reported by Pingdom for my site deployed on AppHarbor are generally around half that for when it was deployed on Discount.ASP, however there are some spikes where the response time jumps to around 26 seconds, what is causing these spikes? My guess is that this is due to app pool recycling, what is the best way to reduce or eliminate these spikes?
The site is using ASP.Net MVC and S#arpArchitecture.
Related
I have a backend IIS server that hosts an ASMX web service. During the past months, this web service has been performing very poorly: requests that usually took around 20ms are now taking around 250ms. After investigating the matter in New Relic, I see that the majority of the time (over 90% of the request processing time - well over 200ms) is being spent on this call:
System.Web.HttpApplication+MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
In all of my other web services, this call takes no more than 1ms.
I have no idea what is this call and why it is performing so poorly. I tried website recycles and IIS resets, but that didn't help. I also tried to google it for hours, but to no avail.
I should also mention that sometimes, for a few brief hours, this problem disappears and the above call is being executed in less than 1ms, as expected.
Any kind of help will be greatly appreciated.
I got website that running on IIS7 that response very slow during weekend night time, after restarting the application pool the website would response fast for certain of time. As time goes (maybe few hours) the website response become slow again.
I open the resource monitor at task manager, and look for the process for the website, the Average CPU is like 6-8, what makes me curious is the Receive B/s go up to 0.8-1MB while the Sent B/s only have 200B, I don't know if that is relevant.
So I was hoping to get an insight of what is the problem here.
Your question is a bit vague. For starters, are we talking a web app, connected to a database? If so, what type of database? There could be any number of causes for this.
But from the sounds of it, I would first start with any database queries you have running. I had a similar issue to yours with a web app, which turned out to be the result of an inefficient SQL Stored Procedure. The site would slow down and grind almost to a halt, but would spring back to life after the app pool was restarted. Rewriting the main Sproc solved the problem.
We have created ASP.NET MVC app which accept file upload(up to 80mb) and has result pooling implemented by AsincController. Hosted on Windows 2008 R2 IIS7.5 .NET 4. Server 2 Cores 2.6GHZ, 2GB Ram, fast HDD.
The web site has many users and Performance Monitor show ASP.NET Requests/Sec ~15 and Request Current ~270
After several minutes ASP.NET starts queuing request and ASP.NET Request Queued counter starts growing and application become extremely slow. I am hunting the problem almost a month, tried to profile code, no performance issues and no memory leaks. Increased maxWorkerThreads to 400 and maxIoThreads to 400. Set maxConcurrentRequestsPerCPU to 5000 and MaxConcurrentThreadsPerCPU to 0 but that either didn't helps.
One thing which seems helps is increasing app pool Maximum Worker Processes to two or three processes and making app pool web garden. After that Request Current jumps to ~350 and no request queuing. But web garden introduce several new issues which we will not mention here.
Please post any suggestions how we could increase application performance without making our app run in IIS pool web garden?
I will say to you to double check the pages that take long time to proceed a work, or the pages that download or upload files, and disable the session on this pages. If this is not possible, then you may need to write a totally custom way to handle the session.
Why, because session is locks everything until the page fully return.
You can read relative to session and to this issue:
call aspx page to return an image randomly slow
ASP.NET Server does not process pages asynchronously
Trying to make Web Method Asynchronous
Web app blocked while processing another web app on sharing same session
What perfmon counters are useful for identifying ASP.NET bottlenecks?
Replacing ASP.Net's session entirely
As the title implies, the first "cold" POST to our MVC3 app in the Azure cloud is very slow. Once it "spins up", the normal requests are blazing fast. The first spin-up after a brief period of rest takes a few seconds. Subsequent requests can be measured in milliseconds.
How can we keep this thing awake?
This is probably due to the appplication pool unloading after a period on inactivity. The next request has to take the overhead of starting it up again.
To confirm this, you need to turn on the performance counters and look at the numbers of app domain loads and unloads.
Either way, this blog post explains how to fix it.
If the leave the webpage (any webpage) on my web application for a while (say 15 min), if I again click on another page it takes a long time to load (20 seconds)
I had a look through the google chrome --> developer module and found that, it is the web page which is the culprit here and the 'LATENCY' time for it is 17 seconds !!! and the actual 'download' time is only 117 ms.
A. what could be the cause of this issue?
B. What can I do to fix it?
thanks.
By default in IIS, your worker processes will idle timeout after 20 minutes and have to be reloaded. This is a configurable setting.
Here's the documentation for IIS6
I am quite certain that it is caused by your worker process recycling. Go to your IIS and check the application pool setting. There is a setting to say that it will automatically recycle after certain time. Either turn it off or increase it
I can't really give you a specific answer here, as I don't know exactly what you may be doing with your application. However, ASP.NET and IIS will not keep everything your web app uses in memory forever. There are two things that could be the culprit here:
1) Your ASP.NET session is timing out, and you are putting something large with a lengthy load in the user session.
2) The IIS app pool is recycling after its idle timeout.
I think that the timeout for both of those is 20 minutes, which would roughly correspond with the 15 minutes or so you are seeing.