Calculate your performance management score and see how much more there is to do. Here Jack Shirazi covers the details needed to make your performance management topnotch.

Application performance management (APM) is how you manage the performance aspects of your application. There are many different issues for you to consider when managing your application's performance, how many do you currently do?

The following list of 30 items lets you calculate what level of performance management your application attains. Give yourself 1 point for each feature that you fully implement (or half a point if you partially implement the feature), and see what you your APM score is out of 30.

• The operating system is monitored on server machines (cpu load, memory usage, paging, file I/O, network I/O, local disk I/O, remote disk I/O, more)
• The operating system is monitored on client machines where these are under your control (cpu load, memory usage, paging, file I/O, network I/O, local disk I/O, remote disk I/O)
• The client experience is monitored (e.g. response times)
• Operating system processes statistics are monitored (per process threads, cpu, memory, I/O)
• JVM and application server level statistics are monitored (GC stats, heaps, locks, deadlock alerting, important methods, pools, caches, object creation, database communications, clustering, failover)
• Database level statistics are monitored
• Component interfaces are monitored (all component boundaries and coarse-grained framework interfaces)
• End-to-end monitoring of important functionality is implemented
• Normal monitoring has less than 5% overhead
• Service Level Agreements (SLAs) are defined for technical statistics (e.g. no GC pause over 0.25 seconds, or GC sequential load less than 5%)
• Service Level Agreements (SLAs) are defined for business functionality (e.g. business transaction latency or throughput)
• Business Service Level Agreements (SLAs) specify the costs of and benefits of any breaks
• Business SLAs are accepted by the end-users and managers
• SLAs are ranked
• SLAs are monitored in real-time (where appropriate), daily, weekly and monthly
• SLA breaks are alerted in real-time (where appropriate), daily, weekly and monthly
• SLA breaks and other alerts do not normally occur at a rate more often than a few a day (noise diminishes the value of alerts and should be minimized)
• Trends are monitored and projected forward to indicate when thresholds will break, and projected breaks are alerted with sufficient time to alter the system to avoid the breaks happening
• Higher overhead profiling can be dynamically enabled and disabled in the system for problem resolution and tuning
• Monitoring is recorded and provides sufficient detail so that any problems identified are fully analysable and the causes sufficiently identifiable from the recorded stats to either: resolve; or to reproduce for further investigation; or to identify which increased logging or increased profiling would help identify the issue
• A good simulation of the production system is available as a performance testbed, with harnesses that generate realistic loads and with realistic configurations used
• Performance regression tests are performed for any version releases, which identify any improvements or degradations in performance from changes to existing features
• Performance regression tests are fully automated
• Load tests are run which identify where the current system will break and the headroom available in the current system before throughput or responses begin to degrade below SLAs (run at least once per year for any significant architecture components)
• New features have new SLAs defined and are performance tested against those SLAs prior to release to production
• The same monitoring capabilities in production are used in performance testing and for performance tuning (using higher overhead profiling where necessary)
• New features are analysed for capacity requirements, SLAs and performance requirements, from the requirements stage (i.e. prior to design)
• Performance requirements are considered at design and implementation phases to ensure targets will be met within the existing or proposed architecture
• The performance team have code-level performance tuning and memory tuning experience, and experience of eliminating memory leaks (or unintentional object retention)
• The performance team have JVM tuning experience

Your score out of 30 indicates how far you are from a comprehensive solution to managing the performance of your projects.

Do you have questions you think should be included in this list? Tell us and we'll update the list with your suggestion (credited to you) if we think it fits