Comments
4 comments
-
Hopefully tomorrow or early next week. We have most of the engine code done and just need to update the UI to allow access to it all.
I will post in this thread once we have released the build.
James -
We make use of WCF as well as ASP.NET handlers and modules (IHttpHandler, IHttpModule). In the past, the only product that we've found that can profile these environments has been the YourKit .NET Profiler (http://www.yourkit.com/dotnet/index.jsp). Hopefully ANTS 4 will be helpful for our environment as well.
YourKit allows us to profile in production environments. We work with very sensitive data that makes reproducing production scenarious VERY difficult. Sometimes profiling a scenario that only occurs on a production box is the only solution available to us.
So, a few things I'm looking for to make profiling a production environment feasible within ANTS:
(1) ability to attach the profiler to a running process
(2) remote profiling capability (e.g., VS remote debugging tools)
(3) a low-overhead profiling mode for long-running profiling
Microsoft provides an *excellent* model to follow with their "Remote Debugging Tools" that come with Visual Studio .NET. We've used this countless times to debug and profile ASP.NET and WCF applications on servers.
I hope to be able to do the same using ANTS. Any chance of that in this version?
-Jonathan -
Hi Jonathan,
Thanks for your comments,
First let me address your requests for ANTS Profiler 4:
This will not be supported in ANTS Profiler 4. It was a very difficult decision to make as it is somthing which is requested fairly regularly but the limitations it would have placed on us would have stopped us doing a lot of the things we wanted to.(1) ability to attach the profiler to a running process
In a little more depth: There are two (sensible) ways to profile a .NET application when writing a profiler the first is is "sample" the application every x ms and see what its doing - this will lead to the lowest overhead but the results returned will be significantly less accurate as you only have partial data about the run.
The second method is to "instrument" the application - this is where you change the application when it is JIT compiled though a hook the Microsoft makes available so that it fires events when certain things happen. This is the approach we take as it provides more complete data but overhead can be more of a problem (something we have worked very hard to reduce in V4). This approach also requires us to [re]start the application so that we can register our handlers with the .NET framework and hook into the JIT Compilation phase.
I have not looked into it directly but one of our customers told me that Yourkit takes a third approach which, when evaluating the possibilities for V4, I did not feel happy with. What Yourkit apparently do is register their hooks system wide so that they profile every .NET process on the machine regardless of if you want it profiled or not and "attach to process" just makes the profiler start reporting results. I think they might have some stuff in there to minimise the impact when you are not attached (or at least I hope they do!) but I didn't feel happy following them down this route of loading ourselves into every .NET process as the moment you load the profiler it changes how function calls are handled in the CLR and thus possibly altering the behaviour of the application on that machine, something I would strongly discourage on production systems.
I do not think this will make it into 4.0 but it is certainly on our list for future versions. Would this be less useful without the attach to process funcationality?(2) remote profiling capability (e.g., VS remote debugging tools
We offer 3 modes of profiling in Version 4 with varying levels of overhead. The overhead has been significantly reduced in comparison to any other instrumenting profiler on the market in V4 and hopefully those 3 modes should provide you with the flexibility that you need. If the profiler overhead is still too high with "Methods with source code mode" please let us know as one of our main aims has been to remove as much overhead as possible.(3) a low-overhead profiling mode for long-running profiling
Sorry for a not very positive reply
We are seriously considering point 2 for future versions. I doubt that point 1 will every be supported via the UI but we might at some point put it in for power users to use but I would want them to be aware of what they are doing first
Thanks once again for the feedback,
James -
James,
I'm most impressed with the tone and attitude of your response. You could have said that you just didn't have it in the plans and that the features requested here were simply bad ideas. But you didn't, and I applaud that.
A few points I would respond with:(1) RE: ability to attach the profiler to a running process
to "instrument" the application ... requires us to [re]start the application so that we can register our handlers
That's fine with me. I would add that perhaps there should be a way to pre-register the handlers and simply puy them in "no-op or sleep mode". While they'd get called, they would return immediately while in this mode. The advantage of this is to reduce overhead such that it could be run on a production server and activated once a problem is detected or direct observation is otherwise required. Of course one wouldn't want this on all the time, but that is the perogative of the developer/admin (i.e. caveat emptor).
I further encourage you to explore ways to "attach" to running processes without restarting the process. Maybe this means requiring that applications instrument themselves or even pre-register the hooks that are then delegated to ANTS if they want that feature available?(2) RE: remote profiling capability (e.g., VS remote debugging tools)
I do not think this will make it into 4.0 but it is certainly on our list for future versions. Would this be less useful without the attach to process funcationality?
I hope this is on the short list. And yes, it would still be useful if the ability to attach to a process is not available. In our case, the test setup is not feasible on a workstation due to the number of dependencies and complexity of the setup. So, it'd be very useful to be able to profile a remote system by simply installing a proxy profiler service on the target server.
(4) the perogative of "power users" vs support
An additional point I would like to elaborate on is the perogative of the developer. A tool may offer options which can be used in really bad ways -- Visual Studio is a perfect example. From a support perspective, Red-Gate has an incentive to reduce those "power user" options to prevent having to deal with users who don't know better. Taking those potential options out of the GUI is one way to reduce their use by novices that take it the wrong direction. If it means the choice of not having a feature or not having it in the GUI, then that's a choice I'm OK with that if it means we get more power user options.
Over-simplification has been ANTS biggest flaw in the past, and we've not been able to use ANTS for this reason. As much as simplicity rocks, the art of debugging and profiling require tools that are up to the task. This may mean sacrificing a bit of simplicity for the sake of power options.
After all, profiling itself is a power user task. So, instead of worry what inexperienced users might do wrong with the tool, I encourage Red-Gate to take some risks and add more power user features. Put warning signs on these options. Don't offer the same level of support for those options. Charge more for those option to segment your market and to pay for that extra support staff. But, whatever you do, don't skimp on the power user options!
Again, thanks James for the positive attitude and willingness to expand the feature set to meet customer needs.
-Jonathan
Add comment
Please sign in to leave a comment.
Thanks.