We've having a problem at production (IIS + asp.net web forms, a form with devexpress callback panel - kind of a substitute to microsoft's updatepanel), when sometimes server won't respond to a callback - the updatePanel just waits for a response forever.
This occurs from time to time without a stable scenario and we have never encountered such problem on our testing environments.
So, obviously, the reason is something with configuration. I've added some logging and that's what I see:
customer reports this 'timeout' (lets call it so) at, say, 12:00
I see in logs that a request was received by server and successfully processed in ~0.5sec (i.e. time from page creation to unload)
For some reason response did not reach the client.
They say it happens about 8-10 times each working day for each operator. They also say there are no firewalls or other software that may block responses. I'm stuck.
Probably there's an instrument I can ask to install on production environments that will trace and log all http request and responces from server with useful diagnostic information that I can inspect later to see where the blocking occurs?
Pleeeease =))
Related
I am coming across the problem that we are able to monitor IIS queue lengths, but we can't tell from within the application how long a request has been sat there.
That means that when we log our response time, we are logging just the application response time, whereas what is more important to us is the amount of time the user at the other end has been waiting (which will include waiting on IIS queue).
I've had a good browse through the request object and can't find anything.
Any ideas?
Thanks
Mark
I am currently debugging some issue about this.
We have a ASP.NET web application and I am debugging on Cassini. When I tried to use IE and send out the request to the server, some time (e.g. in about 20minutes) is needed to process and then send out the response.
In case of multi-tab IE, I tried to send out the requests in different tab at about the same time to the same server but the response is handled only after the one of the response is sent out.
If a new instance of IE is started and the requests are sent out in these different instances, the server can process and send out the response almost simultaneously. After doing some research I found that IIS express may solve my problem, but I cannot. Anyone has experienced similar problem or have I missed out some really important things to check with first?
Thank you for your help.
This is primarily due to ASP.net's session state variable and the fact that only one request at a time may have R/W access to a particular session (as determined by the SessionID cookie).
Any additional requests requiring any form of session access (since Read/Write is the default) will be blocked until the previous request has been completed.
Based on the following links:
http://johnculviner.com/asp-net-concurrent-ajax-requests-and-session-state-blocking/
https://msdn.microsoft.com/en-us/library/ms178581.aspx?f=255&MSPPError=-2147217396
I think that you miss the point that the session is lock all request leaving only one per time to run.
Read about that and why:
Replacing ASP.Net's session entirely
Also : Web app blocked while processing another web app on sharing same session
The reason is that Sessions in ASP.NET are not thread safe. Therefore ASP.NET serializes access to requests from the same session.
If you have a multi-tab IE then your tabs share one session. The first request is executed right off and the other ones are queued. If you have different instances then each of them creates a new session and therefore the request are executed in parallel.
I have a custom IHttpModule that is used to log all HTTP requests and responses, and this is currently working very well, but I'd love to extend it so I can determine how long a response actually takes.
The response is logged in the HttpApplication.EndRequest event, but this event fires before the request is actually sent to the web client. While this allows me to determine how long it took for the server to process the response, I'd also love to be able to time how long it actually took for the client to receive the response.
Is there an event, or some other mechanism, which will allow me to intercept after the client has finished receiving the response?
So that would require client-side code. But not entirely clear what you are wanting to measure. From smallest to largest, the timings could be
time inside server application - measured by code which you already have.
Your code can set the start from either the "Now()" when it begins, or using the HTTP objects. The first call to a site would see a big difference between these start times, otherwise they should be almost identical.
time on server website - I believe this is already measured by most hosting services like IIS.
server machine - I believe this is what "mo" is referring to. You would have to have some kind of external monitoring on the server machine, ala WireShark.
client machine - again, you would have to have some kind of external monitoring on the client machine. This would be the hardest to get, but I think is really what you are asking for.
client application - this is what you can measure with javascript.
Unless this is the "first call" (see Slow first page load on asp.net site or ASP.NET application on IIS7 - very slow startup after iisreset), I believe that all of these time will be just so close that you can use a "good enough" approach instead.
If you must have a measure of this call's client time, then you are stuck in a bad spot. But if you just want better numbers, just continue to measure 1. (application time) with what you already have, and make sure to also measure the size of the request and response.
Then set a base-line for adjusting that time, by testing on various target client machines.
Measure ping times from the client to your server
Measure transfer times of moderately large content - both upload and download
Finagle the numbers to get your average adjustment
You should end up with a formula like:
[AdjustedTime] = [PingTime] + [ServerTime]
+ ([UploadSpeed] * [RequestSize])
+ ([DownloadSpeed] * [ResponseSize]);
This would be the expected client response time.
yes you could handle HttpApplication.EndRequest
another way could be to hook (example: windows service to write response-time to a database) into your webserver (IIS) and trace those events.if you want to analyse the time, a client needs to get your content.
but i think, iis is already able todo so.
it depends a littlebit, what you want todo.
We have a SOAP web service running on ASP.NET Web Services over IIS6 that exhibits a strange behavior when it processes a request that results in long server-time processing. Essentially if a request takes more than about 5 minutes to process on the server then IIS never sends the response back to the client, even though, from ASP.NET's perspective, the call completed. We know this because we write entries to an application log at the beginning and end of a web method call and those log entries do get written. However, no response is actually sent and the connection remains open, seemingly indefinitely. In one test, we saw the connection stay open for over 24 hours before we manually stopped the test client.
We have a test SOAP client that is able to detect the moment a response starts streaming down to it from the server and in the case where the server processing time takes too long, nothing is ever streamed down. Even with a large response payload, we should start seeing that response trickle down shortly after the web method's "end" application log entry is written, but we never see it.
The exact server processing time where things behave in this manor is hard to determine. We have one long-running test call that results in about 2.5 minutes of server processing time and that call results in a successful response to the client. We have another that takes about 8 minutes and that one fails as described above. So the threshold must be somewhere in between.
I suggest that you call a web method to start the execution of your needed task, than use another method to poll the server for the task's completion. I had the same problem 2 years ago and i solved it this way. The client queues a task on the server then after some specified intervals asks the server for the result of the task.
I hope that helps.
I'm encountering a situation where it takes a long time for ASP.NET to generate reply with the web page (more than 2 hours). It due to the codebehind running for a while (very long, slow loop).
Browser (both IE & Firefox) stops waiting for the reply (after about an hour) and gives generic cannot display webpage error (similar to what you would see if you'd try to navige to non-existing server).
At the same time asp.net app keeps going (I can see it in debugger) and eventually completes.
Why does this happen? Are there any settings in web.config to influence this? I'm hoping there's a timeout setting that I'm missing that's causing this.
Maybe a settings in IE or Firefox? But I think they wait while the server is keeping connection alive.
I'm experiencing this even when I launch app in debug mode (with compilation debug="true") on my local machine from VS (so it's not running on IIS, but on ASP.NET Dev Server).
I know it's bad that it takes so long to generate the page, but it doesn't matter at this stage. Speeding it up would take a lot of extra work and the delay doesn't really matter. This is used internally.
I realize I can redesign around this issue running logic to a background process and getting notified when it's done through AJAX, or pull it to a desktop app or service or whatever. Something along those lines will be done eventually, but that's not what I'm asking about right now.
Sounds like you're using IE and it is timing out while waiting for a response from the server.
You can find a technet article to adjust this limit:
http://support.microsoft.com/kb/181050
CAUSE
By design, Internet Explorer imposes a
time-out limit for the server to
return data. The time-out limit is
five minutes for versions 4.0 and 4.01
and is 60 minutes for versions 5.x, 6,
and 7. As a result, Internet Explorer
does not wait endlessly for the server
to come back with data when the server
has a problem. Back to the top
RESOLUTION
In general, if a page does not return within a few
minutes, many users perceive that a
problem has occurred and stop the
process. Therefore, design your server
processes to return data within 5
minutes so that users do not have to
wait for an extensive period of time.
The entire paradigm of the Web is of request/response. Not request, wait two hours, response!
If the work takes so long to do, then have the page request trigger the work, and then not wait for it. Put the long-running code into a Windows service, and have the service listen to an MSMQ queue (or use WCF with an MSMQ endpoint). Have the page send requests for work to this queue. The service will read a request, maybe start up a new thread to process it, then write a response to another queue, file, or whatever.
The same page, or a different, "progress" page can poll the response queue or file for responses, and update the user, assuming the user still cares after two hours.
For something that takes this long, I would figure out a way to kick it off via AJAX and then periodically check on it's status. The background process should update some status variable on a regular basis and store it's data in the cache or session when complete. When it completes and the browser detects this (via AJAX), have the browser do a real postback (or get by changing location.href), pick up the saved data, and generate the page.
I have a process that can take a few minutes so I spin off a separate thread and send the result via ftp. If an error occures in the process I send myself an error message including the stack trace. You may want to consider sending the results via email or some other place then the browser and use a thread as well.