JENNIFER Competitive Advantage
- Real-time
- GUI (Easy to Use)
- Active Service
- X-View (Response Time Scatter Graph)
*1) Response Time Scatter Graph (X-VIEW) / Detail Individual Transaction Profiling
JENNIFER’s response time scatter graph, also known as X-View, displays the response time of all service transactions as plots in a scatter graph. The vertical axis is the response time of an individual transaction and the horizontal axis is the end time of each transaction’s runtime.
Using the X-View, user can not only detect the delay in response time for the specific transaction(s) but also the root-cause behind the delay in the response time. The plots may form different patterns in X-View (see above screenshots) that user can use to identify or predict the performance problem. The X-View is a powerful and intuitive tool that is more useful than using many line graphs combined.
1 Why Monitor Service Response Time by Transaction?
Monitor the response time of all transactions individually and focus on the transactions that are
having performance problem and analyze the profiles
Application Performance Management is a process of measuring the performance of application
services, then analyzing the collected data in order to progressively improve the performance of
said application. Application performance is measured by the observing response time of the
services and amount of system resource used by the services in a specific time interval. In the center
of APM is profiling data for the application services, which is the detailed log or record of what was
processed in the application.
What is Service?
The term Service, if used loosely, can be synonymous to term “Application”. In the world of Java
EE Application, Service is an application module that is prepared to receive and process HTTP
request from an end-user. For example, if a user requested the website www.website.com, the
Servlet or JSP that resides in the server is “Service” and the name of the service is the URL. On the other hand, the scheduler that runs in the background is not considered as service. Thus, service
performance is typically measured by observing the number of hits per URL and response time
associated with each of them.
Common problem with measuring performance is the quantity of services. In a typical enterpriseclass
application, there can be hundreds or thousands of service, each constantly and continuously
processing user requests. Thus the biggest concern about service performance measurement is how
to best collect, store, and express the data.
A standard approach is Grouping-by-Task. Service names or processes that completed service is
grouped by tasks or jobs and number of performance services and average response time of services
are calculated, and displayed in graphs and tables. However, Service grouping can often lead to
dangerous trap of averaging. If one or few critical services are suffering from performance
problems, the problem can be buried under data from averages of rest of the services.
To combat this problem, some administrators started monitoring mission critical services
individually and measure performance of remaining services in groups, but still there is remains
problem with averages and also administrator much choose the specific services to monitor by
predicting which services will have performance problem.
No matter how the services are grouped, the problem of averages will persist. Even within the same
application, some service can be fast and some slow depending on special circumstance such as
system status or logic problem
When performing simple reporting for SLA or status checking purposes, average value is sufficient,
but when collecting and analyzing service data for the purpose of optimizing and improving
application performance, all transactions must be monitored and measured individually.
If the specific transaction cannot be identified, the time and resource it takes to identify troubled
service and finding root cause can be long and tedious.
Problem with monitoring large quantity of service transaction data is how to organize and view
them in a understandable way. Using a traditional line graph is only good for average data, thus
useless in monitoring mass quantities. Only way to display them effectively is to use scatter-plot
graphs. When expressed in scatter graph, administrator can see overall status of service transaction
in one graph without loosing the granularity of the performance data. Take a look at the example of
how performance data for individual transaction can be displayed in scatter-plot graph format.
2)Active Service
It is important for architects to be able to understand what the application looks like at runtime and what services are running; however, it is more important how fast system administrators perceive the system status and how fast to deal with the problems. That’s because time is of the essence. To help such users, JENNIFER provides insightful charts and graphs.
