We run our application on .Net Framework 2.0 and IIS 7.5
While checking in New Relic, we found that we take a lot of time in System.Web.HttpApplication.BeginRequest().
We are working on that fact, i.e. trying to disable session on page level, on all those pages where it is not required.
But currently, We want to know how many total requests are waiting in System.Web.HttpApplication.BeginRequest()?
We saw in IIS Request Monitor, that there are a number of requests in BeginRequest at all particular times.
But is there a performance counter or some way thru code that I can know the exact value of such requests?
You have ASP.Net\Requests Queued performance counter to check the number of the requests that are queued and are waiting to be serviced.
More info at: http://msdn.microsoft.com/en-us/library/fxk122b4%28v=vs.100%29.aspx
Related
I have ASP.NET Web API app (backend for mobile) published on Azure. Most of requests are lightweight and processed fast. But every client makes a lot of requests and do it rapidly on every interaction with mobile application.
The problem is that web application can't process even small (10/sec) amount of requests. Http queue growth but CPU doesn't.
I ran load testing with 250 requests/second and avg response time growth from ~200ms to 5s.
Maybe problem in my code? Or it's hardware restrictions? Can I increase count of processed requests at one time?
First it really matters what instances do you use (specially if you use small and extra small instances), how many instances do you use - dont expect too much from 1 core and 2Gb RAM on server.
Use caching (WebApi.OutputCache.V2 to decrease servers processing efforts, Azure Redis Cache as fast cache storage), Database also can be a bottleneck.
If you`ll have same results after adding both more instances to server and caching - then you should take a look at your code and find bottlenecks there.
And thats only general recommendatins, there is no code in a question.
I do have my OWIN application hosted as a Windows Service and I am getting a lot of timeout issues from different clients. I have some metrics in place around the request/response time however the numbers are very different. For example I can see the client is taking around one minute to perform a request that looks like in the server is taking 3-4 seconds. I am then assuming that the number of requests that can be accepted has reached the limit and subsequent requests that come in would get queued up. Am I right? If that's the case, is there any way I can monitor the number of incoming requests at a given time and how big is the queue (as in number of requests pending to get served)?
I am playing around with https://msdn.microsoft.com/en-us/library/microsoft.owin.host.httplistener.owinhttplistener.setrequestprocessinglimits(v=vs.113).aspx but doesn't look to have any effect.
Any feedback is much appreciated.
THanks!
HttpListener is built on top of Http.Sys so you need to use its performance counters and ETW traces to get this level of information.
https://msdn.microsoft.com/en-us/library/windows/desktop/cc307239%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
http://blogs.msdn.com/b/wndp/archive/2007/01/18/event-tracing-in-http-sys-part-1-capturing-a-trace.aspx
I searched threads here and couldn't really find what I wanted. I know asp.net web forms is an old technology, but I need to work on it for now. Let's say I have a method which does some heavy processing. For example, there is a function which creates 300 PDF Invoices, zip it and downloads it to user computer.
Sample Code:
for(int i = 1; i <= 300;i++)
{
PrintPDF(i);
}
Now let's say PrintPDF takes about 30 seconds to print one record, so it will take around 150 minutes to print 300 PDFs. Now from a user point of view, I may choose to quit in between if I don't like. If user closes the browser then
Does the request to print PDF get aborted instantly after user closes the session?
If it doesn't, what can we do to ensure that the request is immediately aborted as soon as user closes the browser.
Http is stateless. That means you can never relay on fact that you'll get notification when user is closing the browser. However you can always implement Dead man's switch. I.E. make a javascript that will send pings to your server every ten seconds or so & treat user that haven't sent "ping" for more than twenty seconds as logged of. As for heavy processing on server side - that's really unfortunate way to go; for instance ASP.NET have maximum time it can spend serving request - check executionTimeout of httpRuntime web.config element (by default 110s). You can increase this value of course - but the application pool can be recycled anyway and also if there will be lot of requests on "heavy processing" you can run out of available processing threads. If the site is accessible over internet that is also great place for DDos attack.
Better way is to create queue (in db/cloud) and windows service that will process this queue asynchronously. Still you can implement this "force kill request mechanism" by storing "close" flag in queue item that will service check periodically & will stop processing if it is set.
Other workaround is to use websockets (SignalR).
I have an aspx page which loads 10 charts asynchronously through Jquery Ajax requests. The requests are being made to Generic Handlers which implement IReadOnlySessionState since access to a session variable is required but it is a read and this way I am not affected by the read write session lock that asp.net implements.
Through the debugger I am able to see that calls are happening asynchronously but it seems that there is a limit as some of the calls are entering the code only after the first few have completed. I am not sure if this is by design on IIS or a property inside the web.config.
Is there a limit of threads that one user/session can have at one time?
The way IIS and asp.net handles threads depends on the version of IIS you are using. There is a limit to the number of workerthreads and there are caps on the number of threads that must be left available. This means that only a certain number of threads can execute at once.
See: http://blogs.msdn.com/b/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx
If your ASP.NET application is using web services (WFC or ASMX) or
System.Net to communicate with a backend over HTTP you may need to
increase connectionManagement/maxconnection. For ASP.NET
applications, this is limited to 12 * #CPUs by the autoConfig feature.
Also from the same article: http://support.microsoft.com/kb/821268
If you have long running HTTP requests from AJAX your best bet is to do asynchronous http request handlers. Then the requests can be waiting on an IO thread, since asp.net has a lot more IO threads than workerthreads.
See: http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45
I have been struggling with a situation on a site where users' clicks generate AJAX requests, e.g. with some visual effect when the response comes. It sometimes happens that the user doesn't wait until the request is done (although he sees a loading indicator) and starts clicking other elements like crazy. Because in principle I cannot and don't want to disable that possibility, I have tried (more or less successfully) to ensure that anytime a new request is fired, the previous one is aborted (client-side) and its handlers are no longer called - whichever request comes last wins.
Although somewhat successfull on client-side, I'm now wondering whether there is some way to simulate a similar behavior at the server. As I cannot really kill the previous request, only disconnect from it, it will still run to the end and consume valuable resources. If the user clicks on 20 elements, he will only see the result of the very last request, but there will still be 20 requests on the server wasting the CPU doing useless work.
Is there some way to implement a last-win strategy for multiple requests of the same resource in the ASP.NET / IIS ? I guess the requests are anyway internally queued, and what I would need is for the IIS when it tries to dequeue the next one, simply have a look whether there are some others and only serve the very last one from the same session.
I know that in ASP on IIS you could test for isClientConnected and abort if client had disconnected.
I believe something similar would exist in most plattforms.
But I do not know how it works with ajax?