The aXes Terminal Server is just a job like any other IBM i job therefore the normal rules of work management and performance tuning apply. However, because aXes Terminal Server is a transaction server there are some additional considerations.

Tuning Guidelines

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

In this section “transaction” is used to mean the round-trip from a user pressing Enter in an application panel until the screen is available for use again.


Possible Solutions

Users experience frequent ‘Application Busy’ messages

Determine the average length, in seconds, of a transaction for your application and set the TSInactiveLimit= directive in the aXes-TS configuration file to that value plus a few seconds.

If you change the TSInactiveLimit= directive then you must also set the –idle-timeout switch on the FastCGIServer directive in the configuration file for the associated application server to value slightly greater than TSInactiveLimit.

For example, if it generally takes 2 minutes to process a transaction then you should set TSInactiveLimit=125 and –idle-timeout 140.




FastCGIServer “/axests” –program “AXESTS.PGM ‘/axes123/configs/aXesTS.conf’” –mt –idle-timeout 140 –authpath ‘admin=/axests/admin/**’

If you need to set the TSInactiveLimit= directive to a value in excess of 300 seconds then you should seriously consider changing the way your application works. Long running tasks (anything that takes more than 5 minutes to complete) are better handled as batch jobs and should be submitted to batch or sent to a data queue for asynchronous processing.

Response seems erratic when many users have active sessions If the number of sessions exceeds 80 to 100 you may need to increase the number of threads in the Terminal Server job. Increase the RequestThreadCount= and ResponseThreadCount= directives by 1 for each group of 80 to 100 sessions.