Options
Profiling HTTPS site that has multiple users hit
Gangadhar
Posts: 1 New member
Hi there,
I am trying to use ANTS Performance Profiler to profile the asp.net MVC application hosted in the IIS in the QA environment. I have random slowness of high CPU usage which pops up daily at some random time when 5 to 8 users are connected. I tried profiling the https://qa.testwebsite.com with Original port (IIS will restart) option under IIS - ASP.net section, it restarted the IIS and created another instance of w3wp.exe which continuously started taking all my RAM and it reached to >8 GB (though my regular w3wp process for www.testwebsite.com takes max. 1.5 GB regularly) and made the system unusable.
So few questions.
- Is this the right approach to profile from IIS - ASP.net? My goal is to keep ANTS profiler running for the whole time and check its profiling when the high CPU usage issue occurs randomly.
- Why does it create another w3wp.exe process while there is already one running for my www.testwebsite.com? This new process is taking too much of RAM and I don't see any processing or requests from IIS - Worker Processes.
- Will the single profiling from server ensure that all the users from different browsers and sessions will be profiled under the same? How does it differentiate between which user's request took more CPU?
- The article here https://documentation.red-gate.com/app9/setting-up-and-running-a-profiling-session/choosing-application-types-and-settings/profiling-asp-net-applications-running-on-iis says "Closing your browser window will not cause profiling to stop.". I have observed it does not do profiling for the new browser sessions.
Thanks in advance
- Gangadhar
I am trying to use ANTS Performance Profiler to profile the asp.net MVC application hosted in the IIS in the QA environment. I have random slowness of high CPU usage which pops up daily at some random time when 5 to 8 users are connected. I tried profiling the https://qa.testwebsite.com with Original port (IIS will restart) option under IIS - ASP.net section, it restarted the IIS and created another instance of w3wp.exe which continuously started taking all my RAM and it reached to >8 GB (though my regular w3wp process for www.testwebsite.com takes max. 1.5 GB regularly) and made the system unusable.
So few questions.
- Is this the right approach to profile from IIS - ASP.net? My goal is to keep ANTS profiler running for the whole time and check its profiling when the high CPU usage issue occurs randomly.
- Why does it create another w3wp.exe process while there is already one running for my www.testwebsite.com? This new process is taking too much of RAM and I don't see any processing or requests from IIS - Worker Processes.
- Will the single profiling from server ensure that all the users from different browsers and sessions will be profiled under the same? How does it differentiate between which user's request took more CPU?
- The article here https://documentation.red-gate.com/app9/setting-up-and-running-a-profiling-session/choosing-application-types-and-settings/profiling-asp-net-applications-running-on-iis says "Closing your browser window will not cause profiling to stop.". I have observed it does not do profiling for the new browser sessions.
Thanks in advance
- Gangadhar
Tagged:
Answers
Just copying my replies from the ticket we have open with you here:
The profiler has to restart the process (or launch a new one on a new port) in order to load the profiler core into it--this allows the profiler to obtain instrumentation-level (method or line-level) results. The profiler normally shouldn't add that much overhead, but we actually recommend against longer profiling sessions as resource-usage can indeed build up over time, which I think is what you're seeing (or is it immediately jumping to 8gb?).
Can I just check- have you already tried attaching to process instead? Using that option will allow you to attach to the already running process without needing to restart it. It also uses Sampling mode of profiling which is a lower-detailed mode, so it can also help reduce added overhead. While it is less detailed than method or line-level timings, it should hopefully still give an idea of where the main issues in code are. I hope that may help!
The profiler should pick up on all requests sent to the URL you are profiling, regardless of browser or session (note that if you are profiling on an unused port rather than original port, it will not pick up on anything sent to the live site). Unfortunately though, it won't be able to differentiate which user the request came from unless each user has unique URLs.
Hm, that is odd! As the documentation says, closing the browser should not stop the session- the profiler should continue picking up on any request sent to the profiled URL until you stop the profiling session. Just to confirm, this is still when profiling on original port? Does the timeline at the top of the profiler go flat after you close the browser?
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?