Liveliness and responsiveness

One of the simpler methods for monitoring the performance of a PingAccess deployment is determining whether thePingAccess server is available and responsive. To help you identify the status of a server, PingAccess provides a heartbeat request endpoint.

Heartbeat endpoint

If the PingAccess server is running, the process of sending a request to the /pa/heartbeat.ping endpoint (or /<Application Context Root>/pa/heartbeat.ping if you have the Use context root as reserved resource base path check box enabled on your PingAccess application) returns an OK browser message and an HTTP 200 status. If the request times out or requires an extended amount of time to return, the server might be overloaded or experiencing other difficulties.

If a request requires more than two or three seconds to return, multiple factors in your PingAccess deployment might be responsible. Develop a baseline for the desired response time by testing the heartbeat endpoint of your deployment at various times. This endpoint can be useful when load balancing a cluster of PingAccess server instances. Some load balancers can alter the number of requests that are sent to a particular server based on the response code received, or the responsiveness of requests that are made to the heartbeat endpoint.

The output of the heartbeat can be modified to provide performance-related information, such as CPU and memory usage, along with response times. The following example shows the JavaScript Object Notation (JSON) data that is returned when the template is changed to show the memory, CPU, and response time in milliseconds.

The following is an example of JSON data showing memory, CPU, and response time in milliseconds:

Example

{"items":[{
	"response.statistics.window.seconds": "5",
	"response.statistics.count": "1",
	"response.time.statistics.90.percentile":
	"129", "response.time.statistics.mean": "129",
	"response.time.statistics.max":"129",
	"response.time.statistics.min": "129",
	"response.concurrency.statistics.90.percentile": "1",
	"response.concurrency.statistics.mean": "1",
	"response.concurrency.statistics.max": "1",
	"response.concurrency.statistics.min": "1",
		"cpu.load": "15.53",
		"total.jvm.memory": "500.695 MB",
		"free.jvm.memory": "215.339 MB",
		"used.jvm.memory": "285.356 MB",
		"total.physical.system.memory": "17.18 GB",
		"total.free.physical.system.memory": "278.45 MB",
		"total.used.physical.system.memory": "16.901 GB",
		"number.of.cpus": "8",
		"hostname": "jdasilva-r",
		"open.client.connections": "1",
		"number.of.applications": "11",
		"number.of.virtual.hosts": "6",
		"last.refresh.time": "1969-12-31T18:00:00.000Z"
	}]}

For more information, see Heartbeat endpoint.

Response time logging

By default, the audit logs record the processing time for each transaction. With audit logging enabled, you can identify the speed with which the PingAccess server processes web and application programming interface (API) application transactions. Depending on your logging configuration, audit logging might not log any transactions. For more information, see Security audit logging.

The following example shows a default audit log with the following information:

Total roundtrip
Proxy roundtrip
Userinfo roundtrip

Example

The following code example shows the processing times in milliseconds, highlighted in bold:

2019-12-15T17:23:12,192|GRmozOujPDDFct8RbtnfJw|tid:wUu9F0vDd9pZPKe4Oc5Ym_-RFCc..9r72.v8c0Y2CUA5qSpvcxKHgd7QoCp|
 81 ms\| 50 ms\| 0 ms| servapp.ext.wal-ping.com [] /SimpleWebApi /:3000| joe| Cookie| 127.0.0.1| GET| /SimpleWebApi/web/web.jsp| 200| | | Web-API| Root Resource| /