Previous     Contents     Index     Next     
iPlanet Application Server Performance and Tuning Guide



Chapter 9   Validating Server Performance


You can monitor and validate server performance regularly to ensure that the methods that you've set in place for high performance are being carried out. The following topics will help you validate iPlanet™ Application Server performance.

In this chapter, we will discuss the following topics:



Monitoring iPlanet Application Server

Monitoring comes under the serviceability part of RAS (Reliability, Availability and Serviceability). Service provisioning is not possible unless we know the dynamic service behavior.

Service providers want to have real time monitoring of application performance, as experienced by users, accessing externally exposed web services. A data center is likely to have monitoring consoles with graphical displays and alert systems that help maintain Service Level Agreements.

Therefore, application and web service containers must provide accurate and easily accessible performance information to such tools. Such monitoring can be at various levels, but at the minimum, give a view of the rate at which requests are being processed in the server complex.

Monitoring should be flexible, that is, it should be possible to turn it on and off in a running server, without restarts. The data must be well formatted so it can be coupled with various other higher level monitoring tools.

Basically, a well-tuned system should show the following performance:

  • An even usage of CPU time across all of the servers.

  • An even usage of CPU time across all processors in each server.

  • An even usage of CPU time across all of the KJS or KCS processes.

  • A fairly low percentage of system time (0 - 25%), especially if the workflow is computationally intensive.

  • Full utilization of all processors allocated to the KXS process.

Use the iPlanet Application Server Administration Tool (iASAT) to monitor KXS and KJS/KCS statistics. Look for requests waiting while the processors are not completely busy to indicate that the server is not tuned optimally. Check active database connections in the KJS/KCS engines to help set the appropriate number of connections for the DB connection pooling.


On Solaris

For a standard installation, it is difficult to observe the amount of processing time used by each process. However, if you pbind each of the iPlanet Application Server processes to a separate CPU, mpstat will show the percentage of time each CPU spends. mpstat will also display the ratio of user time to system time for each of the processors. proctool (available at http://www.sunfreeware.com) is a very handy tool that shows resource usage per process. Additionally, it provides a GUI for binding processes to processors and for changing process priorities.

This section includes the following topic:


Adding Plots Using iASAT

To monitor process attributes and validate process performance, you can add plots using iASAT. These plots help you to chart KJS, KCS and KXS process attributes. For information on how to configure these plots, and lot process attribute data, see Chapter 2, "Monitoring Server Activity", in iPlanet Application Server Administration Guide.



Using Performance Tuning Tools


Many commercially available tools can be used to profile the behavior of J2EE applications running on iPlanet Application Server. Most of these tools rely on the JVM Profiling Interface (JVMPI) to obtain dynamic information from a running Java Virtual Machine.

Machine Process, JProbe and OptimizeIt are examples of this class of tools. These tools are used to profile CPU and Memory utilization, inspect objects, detect application memory leaks, detect deadlocks, perform code coverage and other troubleshooting activities, in a development environment. JVMPI adds significant performance overhead and is not suitable for monitoring and profiling deployed Applications.

Selective bytecode instrumentation can be used for more targeted and efficient performance monitoring. While not as informative or powerful, instrumentation can provide more realistic data. Introscope from Wily Solution is an example of such technology, integrated into iPlanet Application Server, from Version 6.0, SP3 onwards.

This section lists procedures for using JProbe, OptimizeIt and Introscope with iPlanet Application Server. We will stick to the Windows version of Application Server, but these products do exist and work in a similar fashion on Solaris.

This section includes the following topics:


Tuning Performance Using OptimizeIt

OptimizeIt is a product that you can use to tune iPlanet Application Server performance. You can download the product from http://www.optimizeit.com. To use this tool, perform the following tasks:

  • Configure the JVM to use the JDK bundled with iPlanet Application Server (JDK 1.3.1_02 with HotSpot).

  • Add com.kivasoft.engine.Engine as the name of the class file to be invoked.

  • Add all the entries separated by a semicolon (;) that you find in the classpath entries in iPlanet Registry, to the classpath in OptimizeIt. You are now ready to start profiling.

On Solaris, the steps are very similar to those on Windows NT. However, OptimizeIt is certified to work only with the Reference JDK 1.2 for Solaris and this is not bundled with iPlanet Application Server 6.0.


Tuning Performance Using JProbe

JProbe is a third party tool that you can use to tune iPlanet Application Server performance. To know more about how to install and use Jprobe with iPlanet Application Server, go to http://www.jprobe.com/software/support/jprobe/j2ee/iplanet.html.


Tuning Performance Using IntroScope

Introscope needs to instrument all the desired application class files to gather profile information. This instrumentation can be done statically by hand or dynamically, by integrating this with iPlanet Application Server internal class loaders.

We recommend the second approach because it is more seamless and can be dynamically controlled without changing the deployed bytecodes on disk. To learn more about Wily Tech's Introscope, visit http://www.wilytech.com.

Integrated support for Introscope, with dynamic bytecode instrumentation, is available in iPlanet Application Server, Enterprise Edition 6.0, SP3 and later.



Setting Up SNMP Monitoring


SNMP is a protocol used to exchange data about network activity. With SNMP, data travels between your application server and a workstation where network management software is installed. From this workstation, you can remotely monitor your network and exchange information about network activity between servers. For example, using an application like HP OpenView, you can monitor which iPlanet Application Server machines are running, as well as the number and type of error messages your application servers receive.

Your network management workstation exchanges information with the application servers in your enterprise through two types of agents: the subagent and the master agent. The subagent gathers information about an application server and passes that information to the master agent. The master agent exchanges information between the various subagents and the network management workstation. The master agent runs on the same host machine as the subagents with which it communicates.

To know more about how to set up SNMP monitoring, see "Configuring SNMP to Monitor iPlanet Application Server Using Third-Party Tools", in iPlanet Application Server Administrator's Guide.



Obtaining Performance Data


The web request process flow passes from the load generator to the Web server front-end, and through the in-process iPlanet Application Server Plugin to the KXS process and onwards to a target KJS process for execution. The response retraces a similar path. The trip time can be computed at 4 points.

At the Load Generator. If you are using tools like SilkRunner or another custom load generation tool, these tools already provide measurement and graphing methods. These tools measure the actual response time as would be experienced by real users.

At Web Server.. It is possible to configure the iPlanet Web Server to gather response time profiles. Consult the Web Server Performance tuning and Analysis Guide.

At iPlanet Application Server Web Plugin. . This measures the amount of time iPlanet Application Server takes to respond to a request. It is measured from the perspective of the web connector - the time a request is sent out to iPlanet Application Server till the time a response is received at the Web-Connector Plugin, executing in the web server.

To get these logs, enable the following key at the iPlanet Web Server server in iPlanet Registry:

SOFTWARE\iPlanet\Application Server\6.0\CCS0\HTTPAPI\NASRespTime=1.

This will dump timing statistics on the web server's log files. To extract timing information, execute a composite shell command that could look similar to:

grep "plugin reports" errors| grep -v Registry| cut -c2-21,64- | cut -d " " -f1,2,4

A sample output is shown below. The time is measured in milliseconds:

22/Sep/2000:19:36:09 </NASApp/tmf/TMFServlet> 420

22/Sep/2000:19:36:10 </NASApp/tmf/TMFServlet> 600

22/Sep/2000:19:36:16 </NASApp/tmf/TMFServlet> 392

22/Sep/2000:19:36:16 </NASApp/tmf/TMFServlet> 220

22/Sep/2000:19:36:16 </NASApp/tmf/TMFServlet> 428

The KXS logs at the iPlanet Application Server server (located at <IAS_HOME>/ias/logs/KXS) maintain the reqstart and reqexit times of each request. The reqexit value provides the processing time of each request. This can be used to measure the time taken at iPlanet Application Server to execute a servlet or JSP request.

Setting the following key to 1, in iPlanet Registry, is a useful monitoring trick:

Software\iPlanet\Application Server\6.0\CCS0\REQ\debug=1

You should start to see entries in the KXS log, for example:

[26/Apr/2001 11:48:05:7] info: NSAPICLI-012: plugin reqstart, tickct:

988310885s 763786us

[04/26/01 11:48:05:768] Request 00 Starting AppLogic

{1A488137-7510-1941-BAE5-080020B90F48} on Engine 0

[04/26/01 11:51:07:504] Request 00 Completing AppLogic

{1A488137-7510-1941-BAE5-080020B90F48} Execution

[26/Apr/2001 11:51:07:5] info: NSAPICLI-009: plugin reqexit: 181s

741781us

Request # starts at 00 and increments

Using data gathered at these probe points, it is possible to accurately determine the time taken for each leg of the request round trip. If the number of threads processing requests in any queue along the path is inadequately configured, queuing delays will dominate the response time. Configure iPlanet Application Server and iPlanet Web Server as we have suggested in this document, and focus attention on application performance tuning.


Previous     Contents     Index     Next     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated March 06, 2002