The aXes Application Server is just a job like any other IBM i job therefore the normal rules of work management and performance tuning apply.

An application server has a number of different finite resources, namely; memory, CPU, disk I/O, connection, and network bandwidth. Typically, application servers reach the limit on network bandwidth before they run out of other resources. It takes a small amount of CPU and memory to consume all of the available bandwidth. Smaller responses use less main storage, CPU, disk I/O, and network bandwidth; therefore pre-compress your files. Smaller responses also use a connection for less time.

Tuning Guidelines

An iterative process to tuning is required but the following table may be used as a guideline for tuning the aXes Application Server.

Problem

Possible Solutions

CPU utilization is high or CPU availability is a problem Pre-compress files.
Disable CERN logs and tracing.
Set timeouts to the minimum required.
Limit the use of SSL to URIs that require security.
Exceeded connection limits Pre-compress files. Disable connection persistence.
Decrease the persistence timeout.
Decrease the persistence threshold.
Add additional URL patterns to the CompressList.
Create additional instance(s) of aXes Application Server.
Network bandwidth utilization is high Pre-compress files.
Add additional URL patterns to the CompressList.
SSL slows the responses unacceptably Pre-compress files.
Enable persistence.
Enable compression.
Add additional URL patterns to the CompressList.
Responses are slow on Web pages that contain a large number of URLs. Enable persistence.
Disable CERN logs.
Disk activity is high. Pre-compress files.
Disable CERN logs and/or tracing.
Memory limitations or high swap rates. Pre-compress files.
Add additional URL patterns to the CompressList.

Tuning Guidelines Summary

Experiment.

Set all timeouts to the minimum required.

Use FastCGI for high volume and large requests.

Always enable compression for file based URL's that compress well such as .txt, .html, etc.