Performance Guide

[Fabian Seibt]

Hello,

performance issues with KIX can have a variety of causes.

A first approach can be the analysis of the process list using the tools top/htop. At this point you see immediately whether the CPU cores or the RAM are fully utilized.
Furthermore you can recognize frozen processes (Apache2, MySQL, PostgreSQL, ...).
For the case that hanging processes are responsible for the performance issue, it is recommended to restart services for short-term elimination.

If the error occurs repeatedly, the analysis must be continued. For further research the following questions should be considered:

1. Is the system generally slow or can it be limited to specific masks?
          If it is a specific mask, activating the performance-log can help to analyze this more precisely.
          It may also occur that the display of a specific ticket is very slow because there is a large amount of articles in this ticket, or a certain article has a high amount of lines.

2. Do you use a proxy?
          If a system is tested locally and after that transferred to a server landscape that has a proxy for access, access via proxy will take longer than local.
          In this case, an optimization of the server resources is not effective.

3. Is the hardware / virtualization configured optimally? Are other virtual machines in my environment affected?
          Once a virtualized environment is used and the error also occurs in other systems, the storage system can be the cause.

4. How many agents are working concurrent with the system? Is it a specific performance peak?
          Such a peak at the morning should not be a reason for changing the system. This can happen, as soon as all agents login at the same time.

5. Do I have local or remote connections? (LDAP, database, etc ..)
          A bad / slow connection in your system environment can also be the cause of the problems.
          It is also necessary to check whether several customer data backends are connected, how well their connection is, and if the CacheTTL is configured optimal.

6. Is the CMDB used? If so, how many CI's exist in the system?
          When using KIX Base, access to the CMDB becomes slower with increasing number of CI's.
          This is due to the type of storage in the database and can be fixed by upgrading to KIX Professional.

7. How many tickets, articles and attachments do I currently have in my system?
          As the number of tickets, articles or large attachments increases, the system's load increases. At this point it is necessary to react accordingly.

8. Which filesystem is used? Which io-scheduler is used? Are the article data stored on the filesystem?
          Under certain circumstances, the performance of the storage system or the HDD may be exhausted. The performance may e.g. be measured and analyzed using the iostat tool.
          In very extreme cases, the error log of the apache2 webserver also provides an indication.

9. How is the mailing configured? (pickup, delivery, connection)
          E.g. the postmaster mail service has partial problems as soon as a very large or faulty mail is collected. It si possible that the process will hang then and a new process is started even though the old one is not finished yet.
          This behavior can restrict the performance of the system. If this error occurs more often, a change from postmaster to fetchmail, can be a solution to the problem.

10. Is the swap used in my system?
          As soon as a linux system regularly starts to use the swap, the random access memory (RAM) is not enough for everyday use. In this case, the RAM has to be adjusted accordingly.

11. Is the database on the same server as the application?
          In the case of a performance issue with a local database, it is important to dimension the RAM sufficiently.
          If the performance of the RAM is exhausted, it may be advantageous to outsource the database to a separate server.

A little tip to the conclusion:
The principle "the more the merrier" is not always applicable! For example, if you put more RAM in your system, it must be ensured that this is also fully used. (e.g. DBMS or KIX have to be configured accordingly)
best-practice: start as small as possible, monitor key values and increase resources in small, sensible steps!


Best regards
Fabian