- Define how you will measure the baseline performance benchmarks,
and which measurements you want to optimize.
For example, for some
business applications, it is preferable to reduce the response time for end-users
under peak-load conditions, but for others applications the rate that the
system can process transactions might be more important than the actual duration
of each transaction.
- Make the baseline benchmark measurements under load conditions,
time-of-day, and day-of-week that are appropriate for tuning your application.
- (Optional)
If your enterprise applications use interruptible
processes perform Tuning interruptible processes.
These processes are characterized by having
human interaction and process navigation, which means that their performance
depends on the performance of the process choreographer database and the messaging
service.
- (Optional)
If you are using non-interruptible processes,
perform Tuning non-interruptible processes.
These processes tend to only run for a short
time, do not use the database and messaging support for storing persistent
data (except for storing the process templates), and by definition, they have
no human interaction.
- (Optional)
Tune the application.
There are
many different ways to achieve the same functionality in an application, and
some of them are more efficient than others. Identify and review any performance
critical code. Maximize asynchronicity and ensure that actions are not unnecessarily
serialized. Consider the overhead of serializing and deserializing data that
is passed along a chain of activities. Consider shortening timeouts that do
not result in error conditions. Identify opportunities to cache the results
of database queries.
- (Optional)
Review whether the current configuration
has any performance bottlenecks that can be eliminated.
Possibilities
to consider include:
- Installing more processors, more memory, and faster disks.
- As a minimum, make sure that the database logs are not stored on the same
physical disk as the data.
- If more disks are available, consider distributing the instance table
and the table space for the instance table across two or more disks.
- Not mixing application server and non-application server-related workloads
on the same hardware.
- Use DB2 rather than a Cloudscape database.
- Use WebSphere MQ rather than the embedded messaging provider.
- Buy enough licenses for the message queueing system and database system
to run on enough CPUs.
- If you have a central queue manager setup (one queue manager per cluster),
consider using a local queue manager on any application server whose CPU is
not overloaded. Doing this will eliminate the network delays associated with
process navigation messages, and it will reduce the workload on the central
queue manager - which could help to speed up other processes that rely on
a heavily loaded central queue manager. This will also reduce the load on
the network connection.
- Repeat the benchmark measurements under similar load conditions
to those of the baseline measurements.
Keep a permanent record
of the application's performance measurements to be able to objectively measure
any changes in performance in the future.