Institute of Computer Science AGH Performance Monitoring of Java Web Service-based Applications Włodzimierz Funika, Piotr Handzlik Lechosław Trębacz Institute.
Post on 23-Dec-2015
217 Views
Preview:
Transcript
Institute of Computer
Science AGH
Performance Monitoring of Java Web Service-based Applications
Włodzimierz Funika,
Piotr Handzlik
Lechosław Trębacz
Institute of Computer Science, AGH, Krakow, Poland
Institute of Computer
Science AGH
Agenda
Review of existing monitoring systems• JIMS (JMX)• Lemon (CERN)• Mercury
Concept of a system monitoring WebServices• idea (J-OMIS, OCM-G)• metrics• feasibility study• architecture
Institute of Computer
Science AGH
Monitoring System Funcionality
Monitoring of application is observing, analyzing and manipulating the execution of the application, which gives information about threads, CPU usage, memory usage, informations about methods and classes.
A particular case is monitoring of distributed applications where an additional issue is the performance analysis of nodes.
Institute of Computer
Science AGH
Functional requirements Goals
• monitoring Web Services• distinguishing which objects are interface of WS• accessing information about Web Services on a node
Communication related performance data• size of SOAP message• time of communication• time of parsing a SOAP message
Events• receive request• start/end of creating/parsing SOAP message
Basis• use the J-OMIS interface• hold the existing functionality of J-OCM• make use of experience with extending OMIS/OCM for
parallel applications, grid computing and Java distributed programming.
Institute of Computer
Science AGH
JMX Infrastructure Monitoring System
JIMS is a monitoring service for GRID’s, exposing the following parameters to the outside world:
CPU load, Number of processes, Memory usage, Network interface utilization.
It uses Java Native Interface, Java Management Extension, Dynamic Discovery Service and Web Services
Institute of Computer
Science AGH
JIMS Architecture
JIMS
Node
JIMS
Node
JIMS
Node
Cluster
UserSOAP
GatewaySOAP
RMI
RMI
RMI
Institute of Computer
Science AGH
LEMON (CERN)
Lemon is a scalable and flexible fabric monitoring system. Distributed clients launch and control local sensors, schedule measurements, collect data and send them to one or several repositories. The system provides sensors for common performance and exception monitoring.
Main parts of Lemon are: Monitoring Sensor measures data Monitoring Sensor Agent exists on all nodes and provides
transport to MR Monitoring Repository (MR) with backend to Oracle,
MySQL, flat file,… Alarm Broker – daemon for handling exceptions and
communication between alarm GUI and MR Round Robin Database – is used to store and to
manipulate data
Institute of Computer
Science AGH
Lemon architecture
Alarm GUI
Alarm BrokerMonitoring repository
backend
Monitoring repository RRD Tool Framework
USERSMonitoring Sensor
Agent
Monitoring Sensor
Monitoring Sensor
Node
Institute of Computer
Science AGH
Lemon - Performance Monitoring
In Lemon there are several types of data:• Performance metrics:
• CPU usage, load averages, memory usage, disk usage/performance, sockets, network, …
• Exceptions:• High load, swap usage over 90%, service down,…
• Status information:• Uptime, boot time, kernel version,…
• Heartbeat
Data is gathered with different frequencies from 60s to 1 day/on boot
Institute of Computer
Science AGH
Mercury (GridLab)
The architecture of Mercury Monitor is based on the Grid Monitoring Architecture proposed by Global Grid Forum (GGF), and implemented in a modular way.
The Mercury Monitor provides: monitoring data as metrics, pull and push model, performance monitoring and steering, monitoring of grid entities such as resources and
applications, emphasis on simplicity, efficiency, portability and
low intrusiveness.
Institute of Computer
Science AGH
Mercury (GridLab)
The input of the monitoring system consists of measurements generated by sensors.
Sensors are implemented as shared objects that are dynamically loaded at run-time depending on configuration and incoming requests for different measurements.
Local monitor employs a set of sensors, implemented as loadable modules, to collect information about the local node, including host status, applications, etc., and sends it to the main monitor.
The monitoring service sends requests to local monitors.
Institute of Computer
Science AGH
Mercury architecture
Tool
MM
LM
Sensor
node 2
Sensor
LM
Sensor
node 1
Sensor
Institute of Computer
Science AGH
Idea
Our monitoring system will be based on J-OMIS interface and its implementation, J-OCM.
The work dates back to 1995 when OMIS, a monitor/tool interface specification was released.
Java-bound OMIS is a monitor extension to OMIS for Java applications intended to support the development of Java distributed applications with on-line tools.
J-OMIS specifies three types of services: information (providing information about an object) manipulation (allowing to change the state of an
object) event (trigger arbitrary actions whenever a matching
event takes place)
Institute of Computer
Science AGH
J-OCM architecture
Tool 1 Tool 2
Node Distribution Unit
Local Monitor
(RMI Ext, JVM Ext)
agent
JVM
agent
JVM
Node
Local Monitor
(RMI Ext, JVM Ext)
agent
JVM
agent
JVM
Node
Institute of Computer
Science AGH
J-OCM
Node Distribution Unit is part, which is still responsible for distributing requests and assembling replies.
Local Monitor is a monitor process. LM’s extension provides new services defined by J-OMIS, which control Java Virtual Machine via agent. LM stores information about the target Java application’s object, such as JVMs, threads, classes, interfaces, objects, methods, etc., referred to by tokens.
Agent uses JVM native interfaces such as JVM Profiler Interface, JVM Debugging Interface, Java Native Interface to access low-level mechanism for interactive monitoring of JVM.
Institute of Computer
Science AGH
Grid-enabled OMIS-based Monitor
The OCM-G is a decentralized, distributed system, consists of two types of components:
Service Managers (SM) Local Monitors (LM)
SMs reside permanently, one on each site of the Grid, where are application processes to be monitored.
LMs execute OMIS request accepted from SMs and send the results back. LMs handle only objects which are on the same host. The LMs use OS mechanisms to control the application processes.
Institute of Computer
Science AGH
OCM-G Monitoring Services
The OCM-G provides: Debugging services (services for
suspending/continuing process, reading/writing processes’ memory, etc.)
Performance analysis services, for example:• services for detecting the beginnings and ends of
function calls,• services for handling probes, which are used by the
user to define and detect arbitrary events in an application,
• services for the creation and management of counters and integrators - efficient data structures which allow to buffer and preprocess monitoring information in the context of the application.
Institute of Computer
Science AGH
Components of our system
It contains three kinds of components: application monitor (AM), node's local monitor (LM), service monitor (SM). AM is embedded into the application (in our case Web
Service or application, which use Web Services). It is used to perform monitoring activities in the context of the application. It uses JVM Tool Interface, starting with JDK 1.5, for monitoring JVM.
Node's local monitor is created on each node, where there are Web Services to be monitored. LM receives requests from Service monitor and transfers this request to AM. LM sends a reply from AM to SM.
Service Monitor resides permanently and exposes the monitoring services to tools.
Institute of Computer
Science AGH
Metrics
Our monitoring system have two types of metrics: static – for WebServices, intended for observation and
analysis of SOAP messages sended to and from a Web Service (requests and responses):• number of WebServices on a node• request time, transport time, cache access time,
response time, SOAP create/parsing time, computing time
• size of SOAP message (sent, received)• usage (node resources)
dynamic – oriented towards applications which use WebServices:• function call, service invocation• number of exceptions (errors)
Institute of Computer
Science AGH
Feasibility study
To build the Web Service we use Jakarta Tomcat and Apache Axis.
Jakarta Tomcat is the servlet container: open source, reference platform, simplicity of use, universal tool for deploying web applications.
Apache Axis is an implementation of the SOAP protocol and enables creation of web services on Tomcat.
J-OCM will be a low-level layer of the architecture extended by a special extension for web services.
Institute of Computer
Science AGH
Architecture
Tools
Service monitor
node's local monitor
Node
node's local monitor
AM
Node
WebService
WebService Tomcat+Axis
AM
WebService Tomcat+Axis
AM
WebService Tomcat+Axis
AM
WebService Tomcat+Axis
Service monitor
Institute of Computer
Science AGH
Thank You !
top related