Tuning entails the repetitive process of:
- Running performance benchmarks to identify bottlenecks.
- Tuning components individually and re-running performance benchmarks.
- Increasing the workload to identify all bottlenecks, until the
objectives are met.
There are two main types of components that can be tuned:
- Third-party components
Third-party components that can be tuned include:
- Work with the Operating System Administrators to identify
bottlenecks. If the system is maxed out on CPU and RAM, use the
system utilities to identify which processes are taking up all the
resources. Perhaps, some jobs can be run at off-peak hours or deferred,
or run at a lower CPU priority.
- Check all configuration files to ensure they are in sync with
the current releases of installed software. Upgrades may require
updates to old configuration files that can improve performance
overall on the system.
- Track usage patterns on the machines to identify problems and
failures, which can be fixed easily.
- System administrators will be able to provide additional insight
and guidelines to tune the operating systems.
- Verify that the database optimizer runs as recommended to
generate good data statistics. Example: Oracle ANALYZE command creates
optimizer statistics to choose methods of fast access to the data.
If the statistics were not generated properly, performance will
- Fix Indexes. Use EXPLAIN to see what the optimizer does with
SQL statements. Does it do a full table scan? Does the table have
appropriate indexes for the queries?
- Spread the database over disks and I/O channels. For example,
partition tables and indexes over multiple disks.
- Database administrators will be able to provide additional insight
and guidelines to tune the database servers.
Network administrators will be able to
identify and tune bottlenecks with the use of:
- Packet sniffers, such as tcpdump.
- Network protocol analyzers, such as ethereal.
- Utilities, such as netstat, ping, traceroute, and others.
- Network administrators will be able to provide additional insight
and guidelines to tune the network.
Auto-Reload. This feature automatically reloads the web
application if a change is detected. According to Apache, this is
useful during application development, but it requires significant
run-time overhead. This is not recommended for use on deployed production applications.
For example, you can disable auto-reloading of the WebFOCUS web
application file by adding the following syntax in ibi_apps.xml:
For example, you can enable auto-reloading of the WebFOCUS web
application file by adding the following syntax in ibi_apps.xml:
Pre-Compile JavaServer Pages. The JVM interprets a web
application by dynamically compiling JSPs. Over time, the application
will run faster as all files are pre-compiled.
Enable and Tune Thread Pool
- Initial Thread Pool size
- Minimum number of threads
- MaximumThread Pool size.
number of concurrent threads in pool.
- Thread inactivity timeout
- Time spent waiting for client
response before being returned to pool.
- Growable thread pool
- Automatic increase in thread pool
when maximum thread pool size is reached
- Start in non-debug mode.
- Ensure that the application server or web applications do not
have logging enabled at a level of DEBUG. For example, if Tomcat
is enabled with logging, make sure the log level is set to INFO
in the log4j.properties file.
Considerations for Apache Tomcat
The following is specific to Tomcat, but we wanted to cover it
briefly because Tomcat is commonly used.
Tomcat supports many connectors and each can be tuned differently.
In production you may wish to:
- Set enableLookups to “false”.
- Set maxThreads and AcceptCount high enough to handle incoming
- Set compression options.
Remove unneeded applications to save memory and startup time.
For example, Tomcat ROOT applications should be removed, but you
can leave the Manager web application active.
Apache Portable Runtime (APR) Based Native Library for Tomcat
The Apache Portable Runtime (APR) library is fully documented
on the Apache website. It has the following benefits:
- Pre-built for Windows, but must be compiled on other platforms.
- Makes Tomcat a better general-purpose web server.
- Will enable much better integration with other native web technologies.
- Overall, makes Java much more viable as a full-fledged web server
platform, rather than simply a back-end focused technology.
Java Virtual Machine (JVM)
The JVM, which is used by the application server for deploying
and executing web applications can be tuned, as follows:
JVM Server Modes
- Client. Use with short-running applications.
- Server. Use with 64-bit multi-threaded, long-running
applications, such as WebFOCUS.
- Main differences between the two modes:
- How they handle
compiling Java byte code into native machine code.
- How they handle the Java Heap.
- Optimization and thread management.
JVM memory system manages two types of memory: heap and non-heap.
The heap may be of a fixed size or may be expanded, depending
on the needs of an application. Start the JVM with the initial heap
size equal to the maximum heap size. This removes the need for the
JVM to resize the heap.
- You can specify a starting heap size (-Xms) and a maximum
heap size (-Xmx). For example, a minimum heap size of 1024 MB and
a maximum heap size of 1024 MB is specified as: -Xms1024m –Xmx1024m.
- Set the JVM MaxPermSize to 256m. For example, -XX:MaxPermSize=256m.
- To determine the size of your application, use the Windows Task
Manager, or ps or top on UNIX, or print out the garbage collector
log files when running in verbose mode. You can also use a JVM Profiler.
There are documented guidelines for JVM server applications,
some of which are outlined below:
- Unless you have problems with pauses created from garbage
collection, try granting as much memory as possible to the virtual
machine. The default size (64MB) is often too small.
- Setting -Xms and -Xmx to the same value increases predictability
by removing the most important sizing decision from the virtual
machine. On the other hand, the virtual machine cannot compensate
if you set the value too small.
- Use the -verbosegc option to track frequency and times of garbage
collection, then tune the garbage collector.
You can monitor the JVM using:
WebFOCUS Tuning Components
The following are WebFOCUS components that can be tuned:
- Reporting Server
- WebFOCUS Client
This version of this document is not intended to cover application
tuning. However, at the minimum, ensure the following:
- Requests are generating optimized SQL.
- All RDBMS efficiencies are enforced.
The Reporting Server has a built-in performance framework for
core workspace functions and applications. These include the following:
Data Services. The Data Services feature of the WebFOCUS
Reporting Server feature is useful and can be used to:
- Identify the source of an incoming request. For example,
a Data Service can be created to identify requests that were sent
- Manage throughput to the back-end databases. Data Services has
several properties that can control the number of concurrent requests
sent to the database servers.
- Manage system resource utilization by the WebFOCUS Reporting
Servers. Data Services has several properties that can be assigned
thresholds for RAM and CPU usage.
- Create Data Services to service specific application requirements.
For example, create a data service to process all ReportCaster requests.
- Configure and tune each Data Service differently to meet application
requirements. For example, assume you want the maximum user concurrency
rate for live requests to be ten and for batch requests to be three.
You can create two Data services and set different maximum user
concurrency rates for each. Another example, in the following image,
shows limits being placed on the number of concurrent requests a
user can run for InfoAssist, but not for ReportCaster jobs.
Data Adapters. There are a number of tuning parameters,
depending on the types of queries and answer sets being generated.
A subset of these parameters are listed below. For more information,
see the Adapter Administration Manual.
- Enable OPTIMIZATION flags (SET OPTIMIZATION).
- Fetch data in larger blocks (SET FETCHSIZE).
- Set ISOLATION Level RU (Read Uncommitted).
Java Services. This
feature is used for rendering graphical images on the Reporting
Server, as well as for managing JDBC Data Adapters.
the Java Services JSCOM agents for high availability, failover,
and load management.
- Standard JVM tuning parameters can be applied to Java Services
for memory management and garbage collection.
ReportCaster Distribution Server. This is an independent
Java application program. Tuning parameters include:
Maximum Threads. This is the maximum number of active
concurrent threads to manage ReportCaster scheduled jobs that are
ready to be executed. Must be used in tandem with available system
resources, like CPU, memory. This parameter has a default value
of 6, out of which 3 are always reserved for internal use. The remaining three
are used for the Data Server Maximum Connections/Threads parameter
and can be split across one or more server nodes.
if Maximum Threads=15:
- Three (3) threads are reserved
for internal use.
- Twelve (12) threads are available to be used by all of the configured
WebFOCUS Reporting Server nodes.
Data Server Maximum Connections/Threads. Control the
maximum number of concurrent connections made to the WebFOCUS Reporting
For example, if Maximum Threads=15:
Email ZIP. You can distribute the same report using EMAIL,
with the ZIP option to minimize space allocation. You can also ZIP
and distribute active reports for your users, and they can slice
and dice that data without being connected.
- Standard JVM tuning parameters can be applied to the ReportCaster
Distribution Server for memory management and garbage collection.
Report Library. This ReportCaster component can be used
for archiving distributed output from scheduled jobs. Performance
PDF compression. For example, you can schedule a
report that generates embedded graphical images in the distributed
output and store it in compressed PDF format to the Report Library.