Every time I run the homepage of the project I'm working with, it takes so much time to load (6-8 seconds page load time). And checking with webpagetest.org, the initial request takes more than 5000ms or 5seconds for the TTFB.
Environment Set-up:
ASP.Net MVC
IIS 8.5
Upon thorough investigation and checking the IIS tracing Logs, the long wait happens under the ManagePipelineHandler Module with 7515ms/7.5seconds (it consistently happens with AspNetPagePreInitEnter, AspNetPageInitEnter and AspNetPageInitLeave). Sample on the IIS trace log below:
IIS Trace Logs where the hang happens
And as I search on what does the hang on this ASP.NET events means, but I can't find any concrete answer on what causes this hang or why this hang happens.
Any help is much appreciated.
First of all, you could try to disable anti-virus.
To figure out the root cause, it is recommended to dump file because the long wait happend in ManagePipelineHandler.
We may need to capture 2-3 dump files by generating a dump every 2 second.
Then we can compare the managed call stack. It will tell us what the thread is doing. We can improve the peformance only when we know what it was doing.
If you are not sure how to analyze dump file, then you could try
https://www.microsoft.com/en-us/download/details.aspx?id=58210
If you know how to analyze a dump file, then you could try mex extension with WINDBG.
!mex.aspxpagesext will show all current requests hand its thread.
As long as we know the thread ID, we can use mex.clrstack2! to show the managed call stack
Related
I've been hunting around my issue for a while, probably the best I've come up with is another Stack Overflow question: How should I perform a long-running task in ASP.NET 4?
I'm in a similar place in that I'm wanting to understand what my options are, but I don't feel I know enough specifically about MVC to come to a view. I'm using MVC 5 but with the 4.8 framework, plus I note that technologies such as SignalR have become available since this question was asked. I was wondering if any experienced MVC'ers could give me a view?
I too have a long running process. More specifically, the user is importing a file. The file is delimited so the import happens line by line. The file might be thousands of lines long. Each line will be parsed and imported in a fraction of a second but the whole operation might take several minutes.
I don't particularly need behaviour to be asynchronous, but because of the length of the entire process I want to regularly update the user on progress. I'm wondering what options I have?
I've got a vague recollection that I might have looked at this problem 20-odd years ago (Classic ASP), and solved it by regular flushes, sending a bit more of the page to the client every few seconds, but I'm trying also to use a _Layout page now, so I've sent the page back already. So I don't think I have that option, even assuming such a mechanism still exists. A bit more recently, but still a while ago, I might have used javascript to poll but everything I'm reading now seems to point me to newer technologies which I'm not sure I fully understand yet.
I'm just wondering how would you solve this problem?
I would not be performing any of the file parsing on the web server, especially if it's thousands of rows long. I would delegate this to a background service of sorts, whether that be a Lambda service in the cloud or a Windows service or a scheduled task. You could then call your SignalR hub from the background task (whatever that might be) to update the progress of the import.
In my ASP.Net MVC application, I have to call to one user defined function. Whenever the page is refreshed, this function is called. Now what is the problem, for the first time, it runs perfect. But when I refresh, as I have put the breakpoint, it goes up and down repeatedly.
That means, debugger goes to line1, will run more than one time, then goes to second line, goes to third line, goes to first line, and so on. I have attached photos below. I am developing applications in MVC4.
First image is first time run. In second image, the line connection.Open() runs three times. It happens for every line. Debugger goes up and down abruptly. I don't know what is wrong with this. Can anybody explain this? Thank you.
It's definitely because of multiple threads running simultaneously.
Use this VS extension to limit your debugger hit on only 1 of the threads : https://visualstudiogallery.msdn.microsoft.com/54ef0f07-ed1d-4b89-b4ae-6506b196f843
Sounds like the sort of thing you see when there are multiple threads calling your code.
Is it possible the code is actually being called multiple times by different threads?
To determine which threads are running when, use the Threads window of the debugger. Go to DEBUG > WINDOWS > THREADS
Here is more information on debugging multi-threaded apps: https://msdn.microsoft.com/en-us/library/ms164746.aspx
This should give you insight into which threads are hitting the breakpoints when.
Then inspect the call stack and see where the calls are coming from.
I'd also consider opening up Fiddler or the Network tab of your browser debugging tools and seeing if there are multiple requests being fired off which is resulting in your code being called multiple times - and then tracing back from there what is initiating those web requests.
I have an application written in Delphi 5, which runs fine on most (windows) computers.
However, occasionally the program begins to load (you can see it in task manager, uses about 2.5-3 MB of memory), but then stalls for a number of minutes, sometimes hours.
If you leave it long enough, the formshow event will eventually occur and the application window will pop up, but it seems like some other application or windows setting is preventing it from initially using all the memory it needs to run (approx. 35-40 MB).
Also, on some of my client's workstations, if they have MS Outlook running, they can close it and my application will pop up. Does anyone know what is going on here, and/or how to fix it?
Since nobody has given a better answer I'll take a stab at how to solve this:
There's something in your initialization that is locking it up somehow. Without seeing your code I do not know what it is so I'll only address how to go about finding it:
You need to log what you accomplish during startup. If you have any kind of screen showing I find the window title useful for this but it sounds like you don't--that means you need to write the log to a file. Let it get lost, kill the task and see where it got.
Note that this means you need to cleanly write your data despite an abnormal program termination. How to go about this:
A) Append, write your line, close.
B) Write your line, then flush the file handle.
C) Initially write your file to consist of a large number of blanks--ensure this is larger than the actual log will be. Write your line. In case of abnormal termination it will retain the original larger file size.
I would write a timestamp on every log item so you can see if it's just processing something too slowly.
If examining the log shows you where the problem is, fine. If, as usually happens, it's not enough you put a bunch more logging between the last item that did get logged and the next one that didn't--I've been known to log every line when hunting a cryptic problem that only happened on someone else's system.
If finding the line isn't enough to pinpoint the problem also dump the value of relevant variables.
Finally, if such intense scrutiny makes the bug go away start looking for an uninitialized variable. (While a memory stomp is also an option I doubt it's the culprit here.)
I have an MVC project, and I'm looking at speeding things up. One thing I'm scratching my head over is the BeginProcesRequest() which I have no control over. Using New Relic I found that this method is, on average consuming 90% of the time required for the transaction to complete.
The code in my controller is pretty simple. It has a look for an action session for the user and redirects to their dashboard if it finds one. there isn't any database calls on the actual page. The only written is:
if (Session["UserID"] != null)
// Perform actions
The BeginProcessRequest() method takes almost 4 seconds as you can see in the screenshot
This can't be something unique to my site? I'm using a small EC2 instance for the server, and although there are other applications running on the site the CPU and memory stay pretty much at 0 throughout the request.
EDIT - Reviewed the following post:
What happens in BeginProcessRequest()?
However as my application is idle when the most time consuming requests take place I can't see how it could be related to competing threads.
I think the issue was with IIS, as after I changed the property of idle time-out in the application pool to be one day it now seems to load much faster on initial start.
I also explicitly disabled the session state on my home controller, and ensured that SQL Server's auto close parameter was set to off.
Got a slightly odd one here.
We have an MVC site that is experiencing some instability. Once a week for the last couple of weeks the site has gone down. We have found that all we need to do to bring the site back up again is 'touch' the web config file (i.e. open it and save it, with no changes). This brings the site back to life immediately and keeps it alive for another week or so.
The site has custom error pages set up so we can't actually see the error that is being thrown, and there is nothing appearing in the IIS logs.
It looks like some kind of memory leak problem, however .NET garbage collector should manage this, right?
Any ideas?
Thanks,
Pat
You should have some kind of logging so that you can see what error you get. I usually use elmah. That will give you the full error message and stack trace. It's pretty hard to say what the problem is without knowing the error. But it can be a memory leak of some kind. Do you use a lot of unmanaged code? The garbage collector can't handle everything.
Touching the web.config forces recompilation and refreshes the app pool. My guess is something is knocking out your app pool, whatever it is will be in the event logs, i suggest you check there.