It is important not to mistake this task with profiling that differs in a few important aspects – even if it is done via explicit monitors in the code and so it might seem to be the same:
- profiling solves primarily performance problems, trying to localize the cause of the slowness;
- profiling is mostly development-time tool, it is used mostly when the problem occurs and its results are most important for developers;
- profiling has often dramatic impact on the performance and is rarely used in production.
While typical use case for Java Simon is:
- you know what you intend to measure and you place monitors exactly where you want;
- you probably plan to track measured metrics for some time and process them later – to see them from the perspective, review trends, etc.;
- results might be important for developers as well as for administrators or business staff.
Of course both worlds intersect in many areas and Simon API has also some functions that are close to profiling. Still there is the difference that the application with “Simon profiling” (for instance usage of the Simon JDBC proxy driver) can run in the production unless the performance is critical. This way you can track things that are hard to track during typical development-time profiling. For instance – you can be hunting some nasty resource leak that will likely not occur during short-term test.
Monitoring with Simon API is not performance tuning in the first place – it is monitoring. That does not mean you cannot use the results to tune the performance. Simons allow you to watch your application and it is up to you how you intend to use those results.
No comments:
Post a Comment