Use this task to improve the performance of long-running business
processes, by balancing the hardware resources.
Why and when to perform this task
Before starting to tune the system, verify that the computer used
is well balanced, that is, that the available resources (CPU, memory and I/O)
are in the correct proportions. A computer with one (or many) very fast CPUs
but little memory or poor I/O performance will be hard to tune. For interruptible
processes, good I/O performance provided by multiple, fast disk drives is
as important as adequate processing power and sufficient memory. For production
systems, it is advisable to use a WebSphere cluster of WPS machines running
the business processes, and a separate machine for the database.
Steps for this task
- On the database machine, make sure that you allocate enough disks.
The WPS machine should ideally have two physical disks; one for the
operating system and one for WPS, in particular for the server transaction
log. If the transaction log is a performance bottleneck, use disk striping
to increase write throughput.
Ideally, the machine running the DBMS
should have a fast storage sub-system (NAS or SAN). If you are using a setup
with individual disks, then a large number of disks is advantageous.
The example below uses eleven disk drives:
- One disk for the operating system and the swap space (page file on Windows,
paging space on AIX, swap space on Solaris, paging space on HP/UX)
- Two disks for the transaction log of the Business Process Choreographer
database, either logically striped or preferably with hardware-supported striping
for lower latency and higher throughput.
- Three or more disks for the Business Process Choreographer database table
spaces in the database management system. If more disks are available, the
instance tables should be distributed over three or more disks. If staff activities
are required, additional considerations apply.
- Two disks for the transaction log of the messaging database. Again, both
should ideally be striped.
- Three disks for the messaging database table spaces. These should be striped
and tablespaces distributed across the array.
When using RAID arrays the optimum number of disks is higher,
given that some of the disks are used to provide failover capabilities.
- Allocate enough memory.
The amount of memory to allocate
depends on the platform:
- For a Windows® system with 3 GB of physical memory and a
local database management system, use the following memory allocation:
- 512 MB for Windows systems
- 1024 MB for WebSphere® Application
Server
- 1.5 GB for the database. Allocate 900 MB for the process database and
600 MB for the messaging database or databases.
- For an AIX® system
with 8 GB of physical memory and a local database management system, use the
following memory allocation:
- 512 MB for AIX systems
- 1024 MB for WebSphere Application
Server
- 5 GB for the database. Allocate 4 GB for the process database and 1 GB
for the messaging database or databases.
Tip: To help ensure optimum
performance, do not allocate all memory to the database, because the files
you use and file caching, for example, also consume memory. Avoid situations
in which data must be swapped to disk because insufficient high-speed memory
is available.
- For the application server, when running Business Process Choreographer,
allocate more than the default amount of memory. Tuning the heap size of the
application server is described in Tuning the application server.
- Observe the network utilization. The performance of
applications also depends on the speed that messages can pass between the
servers and the database server. Where possible, reduce latency in the network.
- Move workload to other servers.
Consider which applications
or subsystems can be moved to other servers.
Result
Your computer hardware is now well balanced.