Application performance counter

The WhaTap agent collects various data related to the application performance. The data can be broadly classified into 3 categories:

• User: Real-time user or visitor

• Service: Transaction, SQL, outbound call count and response, error rate, etc.

• Resource: System and process resource usage

User Counter

User is a client using the monitoring system. In the client, users are counted based on the browser.

In the web system performance, user is important because it is the start point that generates the load. For user tracing, it is required to consider what criteria users are classified with and how to count them.

User types

The WhaTap agent provides various options to identify users.

• Remote IP

  Remote IP is used by default to identify the user. Remote IP has limitations when distinguishing actual users.

• Cookie

  Users are identified using the cookie. UUID is saved in the cookie named WHATAP for all connected clients.

  whatap.conf

  whatap.trace_user_using_ip=false

• Header Key

  Users can be identified using the value passed to the HTTP header.

  whatap.conf

  whatap.trace_user_header_ticket=USER

User counting

Depending on the counting method, it is used differently. Real-time users are measured to see how many users are using the system. Daily Active User is a measure for business management on how many users are interested in the service for a day.

• Real-time user

  The number of users is counted in the last 5 minutes. Users are counted by shifting every 5 seconds. The numbers counted on each server are merged through the HyperLogLog algorithm.

• Daily Active User (DAU)

  The users who accessed the system for a day are counted. The number of users logged in for 24 hours is calculated through HyperLogLog.

Tip

WhaTap collects byte blocks for user data by the server to count long-term users. If the data is merged by HyperLogLog, the visitors for more than a month can be theoretically calculated.

Service Counter

Performance metrics for transactions include the number of SQLs or outbound calls used by transactions, the number of response time errors, etc.

• Transaction Counter

  A counter starts measuring when any transaction is performed.

  • Count
  • Response Time
  • Error Count

• Active Transaction Counter

  It counts the number of transactions in progress.

  • Count
  • Active Status

  Progress status is fixed into five: METHOD, SQL, HTTPC, DBC, SOCKET.

  • METHOD - Calling a general function
  • SQL - Running DB SQL
  • HTTPC - Calling an HTTP outbound API (service)
  • DBC - DB connection is requrested; it is usually taken from the pool
  • SOCKET - Connecting the TCP session

• SQL

  It counts the status of SQL running.

  • Count
  • Response Time
  • Error Count
  • Patch Count

• HTTP Call

  It counts outbound HTTP calls.

  • Count
  • Response Time
  • Error Count

Resource Counter

It counts the server resources or resource uses inside the node processes.

---

• CPU (sys, usr, wait, steal, irq, cores)

  CPU usage %. The data is collected for each type. Steal is meaningful only in the virtual environment. The number of CPU cores is also collected.

• Process CPU

  CPU % used by the process.

• Memory

  System memory usage (%).

• Swap

  Swap memory usage (%).

• Disk

  Disk is the process utilization (%) of the current directory

• Heap (Total, Used, Perm)

  Total, Used, and Perm amounts of the heap memory. The data unit is KBytes.

• DB Connection Count

  It collects the connection pool counts.

---

Apdex

Apdex (Appliccation Performance Index) is a performance metric that complies with the open standards. Apdex is based on the response time and is quantified as percentages of satisfied and accepted requests out of total requests. The Apdex graph has been added to the dashboard.

Apdex can be used as a metric for user satisfaction and have a value between 0 and 1.

(Number of satisfied cases + (Number of tolerating cases * 0.5))/Total number of requests

Status	Description
Satisfied (S)	No problem with the work ≤ 1.2 secs (S as the default)
Tolerating (T)	Users feel delay but working is possible ≤ 4.8 secs (S * 4)
Frustrated (F)	Working is impossible > 4.8 secs (exceeds T and error)

• whatap.apdex_time millisecond

  Default 1200

  The default value (S) can be modified in Agent CONFIG.