I'm using windows 2003, running some classic ASP pages.
frequently client get just a part of the page, looks like the page is not fully generated for some reason (refreshing does solve it).
I checked for a clue in event viewer, but there is nothing there.
Any idea what can cause this behavior?
IMHO this could happen because:
- Browser cache needs to be cleaned.
- Memory corruption or insuficient ram in the client.
I would recommend further testing in several client machines and different browsers.
Related
Using performance monitoring tool "New Relic" I am seeing occasional (but too many) long delays in the "AcquireRequestState". I am talking about 10, 20 second delays, sometimes minutes.
I know we have not written our own event handlers for this event.
Where do I even begin looking for the cause of these delays? The little information I have found so far on msdn has not been helpful.
My team saw this "AcquireRequestState" delay reported by NewRelic earlier today when one of our ASP.NET applications was having performance problems on a particular page.
The root cause turned out to be a change to a stored procedure that we'd recently deployed to our SQL Server database, which was inadvertently causing that stored procedure to take a very long time to execute. The stored procedure was called as a part of displaying the page that was having the performance issue.
We were able to resolve the issue by identifying and fixing the performance problem with the stored procedure. The "AcquireRequestState" issue from NewRelic turned out to be irrelevant; it was a symptom of the problem, rather than the cause.
This was on an ASP.NET 4.5 application running on Windows Server 2008.
tl;dr: The "AcquireRequestState" delay reported by NewRelic may be a side effect of some other problem that's causing one or more of the pages and/or AJAX requests in your ASP.NET app to take a long time to load.
Try to apply Hotfix Rollup 2828841 on the server.
Issue 6
Symptoms
When you send many concurrent requests that have the same
SessionId to an ASP.NET 4.5 web application, some requests may freeze
at the RequestAcquireState stage unexpectedly.
Resolution
After you apply the hotfix, the hotfix makes sure that the
EndRequest event will always trigger.
This hotfix applies to
Windows 7 Service Pack 1 (SP1),
Windows Server 2008 R2 SP1,
Windows Server 2008 Service Pack 2 (SP2), and
Windows Vista SP2.
I suspect your stored proc change might be highlighting a slightly different problem in terms of session locking, we had roughly the same being reported for a different scenario, I'd seriously like to encourage you to test out the async session provider as mentioned here and making sure you use the concurrent requests per session app setting :
https://stackoverflow.com/a/55331786/7581050
Ultimately any long running process (in your case the stored proc change) is blocking any further requests for that session. Since this "block" is happening in a different part of the IIS pipeline, NewRelic simply records it as "AcquireRequestState"
PS: I know this answer comes quite late but I've finally found something that solved a similar problem for us and I suspect will help many people in the future.
What this part is doing? Especially why its time consuming, if I dont have ViewState and big object graph? It can take sometimes 3rd of request speed.
Found that this problem, is only on dev server.
I have also noticed that this stage is comparatively expensive even without ViewState (even with a nearly blank page)
I was able to speed this stage up drastically by running my project on my local IIS instance rather than running on the Visual Studio development web server. Compiling in release mode versus debug mode seemed to give a marginal improvement as well.
My guess is that 1) it is nothing to worry about and 2) the VS web server may be less optimized than IIS for some piece of the process. For example, IIS may cache machine values (such as registry settings, certificates, etc) and the VS web server may not.
If during SaveStateComplete an encryption routine is run (such as when EnableViewStateMac="true"), a call to local machine resources might be much more expensive running on the VS web server even if nothing is actually being encrypted.
I don't consider this a great answer; if you are really concerned you could profile ASP.NET to see what it is actually doing (for example, which BCL methods are being invoked).
the role of SaveStateComplete is to save control viewstate/controlstate before it is rendered. So, unless you have disable viewsate(EnableViewState="false" at page level) for your page/controls, the job is always done. Moreover, disabling viewstate doesn't disable controlstate.
Do you have many controls on your page?
Ok, this is one of those really weird errors that seems like the machine's just messing with you.
We have 2 websites, ASP.NET, both were 2.0, and we upgraded them both to 4.0.
They're the same exact codebase, but the web.config files are different, they point at different databases, and they run as separate web apps in IIS.
After the upgrade, one works and one doesn't.
The one that doesn't work will throw a bunch of javascript errors around the Microsoft AJAX Control toolkit like 'Sys is not defined', 'Type is not defined', and '__nonMSDOMBrowser is not defined' (in firebug). When I use the Scripts panel in firebug it lists all the different '...ScriptResource.axd?d=IOBqtxq...' scripts, but when I ask to look at them, many of them will return 'Failed to load source for: /ScriptResource.axd?d=IOBqtxq7p...'.
A couple of them do come back with the CodePlex copyright and some javascript, but many of them don't. And the truly weird thing? If we recycle the app pool for the broken site, we don't get those errors the first time we hit the site. The postback works, we log in, etc. Then we go back and hit it again, javascript errors are back and no postbacks.
Any ideas?
Ok, I hate answering my own questions, but since no one else is weighing in, this is the best we've come up with.
There's a setting in IIS for the website that specifies Web Garden Threads, which I assume is how many threads to use if the site is in a load balanaced web garden. We had this new site set to 7, which is how it was in .NET 2.0. Apparently 2.0 is more forgiving (or ignores it), but 4.0 freaks out. The single request to the site is a request for lots of different resources, which end up being handled by different threads, which as you can imagine makes for chaos. And it's different every time depending on which threads do what.
So, unless anyone else has an explanation for this, I'll close this.
Running many applications out of the same app pool can cause really strange ajax behaviors. Often times you'll see this with apps sharing the DefaultAppPool.
Try creating a separate app pool for the application.
I'm having some problem finding the source of the problem, but here it goes, maybe you know the magic answer.
I'm running this asp.net site with an AJAX updatePanel on my local machine, and everything works just fine, since it's where I developed it. Now, a few days ago, I uploaded the files to my web-host and assigned every single DataBase, and there is no error messages, even though it's still set to debug mode. There is a problem though, whenever I click an element which triggers my asp.net AJAX updatePanel to update, the whole site is updated(which it should not, only the Panel), and my jQuery's (document).ready is called every time as well.
Thank you for any help, I have no idea why this does not work online, nor' do I know why it does work on my local machine.
I have choosen not to upload the code, since I have no idea where the problem might lie, please feel free to ask for the code and I shall reply :)
Have you checked that your web host either:
a) Is running .net 3.5
b) Has the Ajax extensions for .net 2.0 installed
...and that you are testing locally with the same?
If you don't know what the operation aborted error is, here's a Microsoft KB Article about it, http://support.microsoft.com/default.aspx/kb/927917 . There's also tonnes of posts about it but the simple answer for it's occurrence is this; the error only occurs if you try to manipulate a DOM element via JavaScript before the element you are trying to manipulate is loaded.
I know how Internet Explorer's (IE) infamous Operation Aborted occurs and know how to fix it. The problem I have is a very weird scenario. Testing locally and on a development machine with IE7, I never ever get the operation aborted error (both sites running as http).
However on our client's testing site it occurs all the time. Unfortunately my testing environment is not the same as the client's testing environment, so that adds some variables to the mix, but the main difference I see is that the client's testing site is using SSL.
Has anyone ever had the Operation Aborted error only for an SSL site?
The other thought that popped in my head was that it was a latency issue. Locally the site loads up almost instantaneously whereas on my client's testing site, the page loads slower. So with that in mind, I got Fiddler running and simulated the performance to run at old school modem speeds, still no operation aborted error locally or on our own testing server.
FYI: The site is an ASP.NET 2.0 Site using ASP.NET AJAX Extensions 1.0. The page with the issue also has the AJAX Control Toolkit's Cascading Drop Down on it.
And yes as far as I can tell all JavaScript that manipulates the DOM is at the end of the markup, not the beginning.
Any help or comments is greatly appreciated.
Well after scouring the Internet I found the issue. It has to do with a bug in the the ASP.NET AJAX client-side framework.
I'll paraphrase what I found:
The issue is a race condition that occurs due to an Internet Explorer/ASP.Net AJAX bug. The probability of encountering this issue increases when the application has a significant number of ASP.Net AJAX enabled server controls on the web page. The issue is explained here, http://seejoelprogram.wordpress.com/2008/10/03/fixing-sysapplicationinitialize-again . I have added this fix to the project I'm working on.
This fix is still required if using ASP.NET 3.5 SP1.
I guess the reason why you don't have SSL on your test box is due to the cost of the certificate. Did you know you can get Free short term certificates? I've often used them to sort out issues like this.
For example RapidSSL do a free 30 day certificate.