Activity overview
Latest activity by rgrenfell
I just wanted to state for any that read this thread in the future that indeed this did resolve the issue I'd been seeing. The data when drilled into now provides accurate information on where the time was spent.
I'd like to thank the team here for having given this issue the attention it received and for following up on it to closure. / comments
I just wanted to state for any that read this thread in the future that indeed this did resolve the issue I'd been seeing. The data when drilled into now provides accurate information on where the...
Bart,
I double checked the session data I had captured, and "Accept()" is no in the recorded call stack from what I can see. What I have recorded is:
System.Net.Sockets.Socket.Poll( int microSeconds, SelectMode mode)
---Transition to unmanaged code...
System.Net.UnsafeNclNativeMethods+OSSOCK.select(int ignoredParameter, IntPtr[] readfds, IntPtr[] writefds, IntPtr[] exceptfds, TimeValue timeout)
(Thread blocked)
The select() call reads 76.538 Time With Children (%) while the Thread blocked reads <0.001
To the best of my knowledge, the call to select() is simply performing a blocking wait for data to come through, if this is not the case, then maybe this call is MUCH more expensive than I ever understood it to be.
Hopefully this just has a similar problem to the Accept() call you mentioned. / comments
Bart,
I double checked the session data I had captured, and "Accept()" is no in the recorded call stack from what I can see. What I have recorded is:
System.Net.Sockets.Socket.Poll( int microSecon...
Bart,
Thank you for the update. This does sound like it would be a major piece of the problem that we were experiencing. In response to your other points in your last post, the other approaches unfortunately don't work under the situation I'm in at least. The Threads which I'm most interested in profiling are once that perform these blocking operations.
Do you know if the accept() routine is triggered as part of a socket.Poll() call? If so, what I was seeing would indeed be addressed by such a fix. If not, double check that the routines below Poll() are caught.
Also, unfortunately, it sounds like the filter that you have is an inclusion filter, not an exclusion filter. Although being able to say "I only want to profile this namespace" can be critical in certain situations, when trying to determine a global application hotspot that's not what you are looking to do. However, once you've determined that a specific hotspot either 1) can't be reduced, or 2) in our case, the hotspot is artificial, being able to "exclude" that particular data would be critical in recomputing the next level of hotspots.
Lastly, I specifically included routines for which source code was not available in order to be able to see where time was spent that was not necessarily specific to my code. e.g. utilization of a specific OS call significantly degraded performance, and therefore might warrant modification to another approach.
I really appreciate your having taken a serious look at this so that you've determined that there was a problem that could be resolved. I look forward to taking a look at the data again once your people have had a chance to put out a hotfix. / comments
Bart,
Thank you for the update. This does sound like it would be a major piece of the problem that we were experiencing. In response to your other points in your last post, the other approaches u...
I too would echo Troy here. It's not a requirement to filter during profile capture, but once we've collected the profile data and then go to evaluate the results, it would be useful at that point to exclude specific method calls.
My case is this:
* Watch a socket for incoming data - wait for data to be available using Poll()
* Read the data
* Process the data
The "Poll()" call lists as 76.8333% under "Time with Children(%)" due to the fact that technically we are spending a lot of time waiting for data to come in accross the wire to then be processed. That's time I can't improve performance on. It would be very useful after the session is done to say, Filter Out Poll() and recompute percentages and compute new hotspots.
At that point I'd have a much better picture of where processor time was really being spent in the application.
But it doesn't need to be performed during data collection if that would create a burden on the system performance. It's post processing. / comments
I too would echo Troy here. It's not a requirement to filter during profile capture, but once we've collected the profile data and then go to evaluate the results, it would be useful at that point...