Conceptually
the role of the application server is rather
simple. Application servers comprise the
core business processes and logic within
a distributed N-tier application and act
as the “glue” between client
requests for application services and back-end
data sources. However, there are many configurable
parameters that affect the efficiency of
this process, such as available memory,
the number of available threads, cache
sizes and connection pools, as well as
the workload of the end-user community.
Requests for application data need to be
executed simultaneously and resolved in
a timely fashion with finite hardware and
software resources.
Since the implementation and objectives
of the application server are quite unique
to each individual application, there is
quite a bit to gain by tuning the application
server based upon its specific business
requirements and available resources. For
instance, the following symptoms all have
been experienced within previous client
applications and were solved through incremental
configuration changes within the application
server.
Program Highlights
1. Fluctuating or periodic increases in end-user response times
2. Increasing response times over time
3. Under utilization of one or more servers within the application
4. Connections refused by the application server
5. Memory leaks
6. Limited throughput
7. Java Exceptions
8. HTTP Internal Server Errors
Typical solutions involved tuning the Java Virtual Machine (JVM) heap size and
garbage collection, configuring the number of application server threads that
handle end-user requests, upgrading to a newer JVM or configuring the connection
pool size to a back-end data source.
How can RTTS solve the problem?
Regardless of the specific application server vendor, RTTS has a standard solution
for tuning applications running within any application server platform, such
as WebLogic, WebSphere, IIS/ASP, ColdFusion, JRun, Microsoft Transaction Server
(MTS), CGI/FCGI, etc… The same performance tuning concepts apply to all
application server vendors, although the terminology differs.
1. What level of tuning? – Component-level tuning, such as Java Servlets,
EJB’s, COM/DCOM components, or system-level tuning?
2. Understand the end-user community – Gather metrics regarding the manner
in which the application will be used. What components will have a higher degree
of exposure and pose the greatest risk? What business transactions will be executed?
3. Gather Performance Requirements – Determining the exit criteria for
tuning needs to be established in order to know when sufficient testing has occurred.
4. Automate Test Scripts – Create automated test scripts that can invoke
the necessary component services or drive the business scenario.
5. Execute & Analyze Tests – Run the planned tests and collect metrics,
such as response times, transaction volumes, operating system statistics, application
server statistics.
6. Application Profilers – Implement ancillary tools to profile transaction
characteristics. Determine the network characteristics, CPU utilization, SQL
calls that a particular transaction or component exhibits.
Deliverables
At the conclusion of the project we will provide an Executive Summary report
illustrating the following topics:
• Performance of your application as quantified by response times, throughput,
application and communication errors, system resources and capacity, as related
to the particular application server tuning parameters. For example:
- Performance as a function of application server threads
- Problematic components, such as EJB’s or COM/DCOM components
- application performance as a function of JVM heap size
- Performance related to cache sizes and connection pools
• Steps for moving forward
Also, the engagement will implicitly provide the following:
• A suite of automated test scripts that can be used for future testing
and tuning
endeavors.
• A set of best practices for approaching application server tuning, including
test execution, reporting, analysis and quantifying the ROI.
|
