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

  trace_user_using_ip=false
  
  # Java agent v2.2.0 or later
  wclient_using_ip=false

• Header Key

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

  whatap.conf

  user_header_ticket=USER
  
  # Java agent v2.2.0 or later
  wclient_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 Java process.

• Memory

  System memory usage (%).

• Swap

  Swap memory usage (%).

• Disk

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

• Heap (Total, Used, Perm)

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

• GC (Count, Time)

  Sum of the numbers of GCs and the times that occurred for 5 seconds.

• ObjectPendingFinalizationCount

  The number of objects waiting to finalize() during a GC call. As the value increases, the GC time may be delayed.

• Thread (start Count, Count, Daemon, Peak Count)

  It collects the numbers of threads from the start of JVM, number of running threads, number of daemons, and the maximum number of threads. You can make judgment about whether the thread pool is required.

• DB Connection Count (active,idle)

  It collects the idle count and active count in the connection pool.

• Tomcat Thread Pool (active, queueSize)

  It collects the performance data once the Tomcat's executor thread pool has been set.

  XML

      <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
      maxThreads="50" minSpareThreads="2" maxQueueSize="78"/>

---

DB connection pool counter

DB connection pool is called "DataSource." It is usually provided by WAS, but in some cases, any open source pool is used. Usage data is sometimes exposed as JMX, but not always.

WhaTap provides 2 different methods. The direct inquiry is performed by a single BCI and another method uses JMX. The BCI method is used by default and as a secondary method, the JMX method is provided.

The following is the ByteCode Injection class associated with the default values for each option.

hikari_pool_enabled=false

com.zaxxer.hikari.pool.HikariPool

dbcp_pool_enabled=true

org.apache.commons.dbcp.BasicDataSource
org.apache.commons.dbcp2.BasicDataSource
org.apache.tomcat.dbcp.dbcp.BasicDataSource
org.apache.tomcat.dbcp.dbcp2.BasicDataSource

tomcat_pool_enabled=true

org.apache.tomcat.jdbc.pool.ConnectionPool

weblogic_pool_enabled=true

weblogic.jdbc.common.internal.ConnectionPool

jeus_pool_enabled=true

jeus.jdbc.connectionpool.ConnectionPoolImpl

jboss_pool_enabled=true

org.jboss.jca.core.connectionmanager.pool.PoolStatisticsImpl

Caution

If the BCI-related option is changed, you have to restart the service. Even after a class has been instrumented, it needs to be registered in the tracing table. Accordingly, redefinition does not work during execution.

Importing data sources into JMX

If dbcp_pool_enabled==true, tomcat_ds_enabled=false
If weblogic_pool_enabled== true, weblogic_ds_enabled=false

1. Check the option auto determination details.

2. Declare the option value of the related pool to false.

3. Change the DataSource-related option value to true. The default value is false.

   whatap.conf

   tomcat_ds_enabled=false
   weblogic_ds_enabled=false

ThreadPool counter

ThreadPool counters are collected through the JMX Mbean data. This metric may not be collected in some environments, although collection is fine for many use cases such as Tomcat.

Additional settings are required for collection. The related settings are as follows:

whatap.conf

jmx_threadpool_objectname=Catalina:type=ThreadPool,name="http-bio-8080"
// Set the name of JMX ThreadPool MBean
jmx_threadpool_atter_activecount=connectionCount
// Set the attribute representing the activecount value.
jmx_threadpool_atter_queuesize=maxThreads
// Set the attribute representing the maxThreads value.

Check the Mbean names such as JMX ThreadPool ObjectName and AttributeName through the JMX monitoring tool or see the Mbean documents for each WAS.

Note

See the active WAS and framework-related document and check the Mbean information.

In case of using the Jconsole

• ObjectName : Catalina

  type : ThreadPool

  name : "http-bio-8080"

  

• ActiveName : connectionCount

  QueueName : maxThreads

  

Checking the result

If the setting is finished, you can view the data from the counter as follows:

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.