· Nov 8, 2017 5m read

APM - Using the CSP Page Statistics

Using the CSP Page Statistics

Application Performance Management


A key part of Application Performance Management (APM) is recording the activity and performance of user activity. For many web applications the closest you can get to this is to record the CSP pages or CSP based services being dispatched.

If the pages or service names are meaningful and they indicate the business activity being performed the CSP page statistics can be very useful in building up a historical record of activity, performance and resource usage. This allows you to recognize trends in activity for planning purposes. It allows you to see gradually degrading performance or increasing resource usage so you can take action before you have a crisis. Also, if you do have a performance crisis you can look back to see what has changed since the performance was fine.

In this article I will briefly describe how I like to use the CSP Page statistics to build a record of the application activity and performance.

This article is one of a series about APM and the tools available in InterSystems products to help with APM. If CSP page statistics don’t give you what you need, hopefully one of the other techniques will.

What are CSP Page statistics?

The CSP statistics add monitoring points to the beginning and end of the Page() method that renders the page. These capture details of CSP page or service dispatched including the number of global references, the number of lines of COS and the execution time. Since %SOAP.WebService and %CSP.Rest extend %CSP.Page these statistics apply equally to SOAP and REST services. The statistics are aggregated by page or service for each time period.

The statistics only measure the execution of the Page() method and do not capture statistics about subsequent hyper events.

The CSP gateway also provides statistics and while these are great for diagnosing immediate problems, I have found them less useful for long term monitoring.

What are the costs and benefits?

The cost of gathering the statistics is very low.  The statistics are aggregated as they are written to disk so the disk space taken up by the statistics is also very low and they can be retained for long periods of time. For very busy applications (dispatching hundreds or thousands of CSP pages or services per second) you must check whether the monitoring affects the performance of the application and keep an eye on the added journal space. In these cases you probably want to discuss monitoring with InterSystems anyway.

For a CSP based user interface there will be very little immediate benefit, because you probably have a good idea of which pages are being used and which ones are slow. But for SOAP or REST services it is quite conceivable that this isn’t well understood.

As always the main benefit of building a historical record of usage and performance comes weeks or months later, when you are working on a capacity plan or investigating a performance issue.

How do I configure CSP Page Statistics?

The Page statistics have to be turned on for a page by defining class parameters inherited from the CSP page class. This can be done in individual pages, but it is much easier if your pages and services extend a single super class where you can set the parameters. To turn them on, set the PAGETIMING parameter to 1. You can also control the length of a time slot over which statistics are aggregated by setting the TIMINGSLOTS parameter but I have found the default of 30 minutes works well.

/// If this parameter is true then we automatically record timing statistics of how long it takes to
/// produce this page. It is off by default.
Parameter PAGETIMING = 1;

Because the class has to be changed, the decision to include statistics collection has to be taken by the application developers and can’t be turned on easily by the end users.

If your application has some very lightweight services that get called very frequently, the application developer can turn off statistics from these services while leaving them on for the majority of pages.

How do I access the CSP Page statistics?

Results are stored in ^ISCcspPerformance in the %SYS namespace. The results are  stored in a very simple global structure which is exposed to SQL through the table %CSP_Util.Performance. For each timing slot every page that has been executed in that slot is listed as six entries with the hit count and usage statistics. All the values, except min and max are totals for the timing slot. So Figure 1 shows the totals for the web service MyApp.MyServiceClass.cls for one 30 minute timing slot.

























Figure 1 CSP Page Statistics global

Limitations of CSP Page Statistics

While being useful in many cases there are lots of cases when they aren’t able to give meaningful information. The main cases that I have come about include

  • Some applications use the same web page as a container for everything and the content is context driven. In these cases everything appears under one page name which isn’t useful.
  • The statistics don’t include the name of the action for web services, so all the actions implemented in a class are grouped together.
  • The statistics only measure the server side timing when rendering the page. It doesn’t include the time to execute java script or the time to execute hyperevents.

Recognizing what the CSP page statistics can and can’t do you can decide whether they can help manage the performance of your application.

Discussion (1)2
Log in or sign up to continue