Page tree
Skip to end of metadata
Go to start of metadata


For customers with a valid subscription we can offer a more extensive tuning and optimisation document. Please request it from our support portal.

Measuring Kopano performance

Kopano Stats

Kopano Stats is a command line tool to show various statistics about the health and performance of your Kopano Core installation. It can show several types of statistic tables (system metrics, active sessions, users and user-settings, companies, as well as a live "top"-like overview of the Kopano Core server. Calling Kopano Stats can be done with the following example command;

$ kopano-stats --top

And will give you various metrics. The most important ones are explained below;

Round Trip Time

Round Trip Time (RTT) is the most important indicator for your performance, as it measures the time it takes to complete a request. A live calculation of the RTT will be shown with kopano-stats --top, which will fluctuate according to server load.

Anything below 40ms is normal and very acceptable speed, but values above 50ms can give the user some delay in user experience.

Threads (active and idle)

What can also be seen is the amount of Kopano Core server threads, pre-configured in the server.cfg and idle. A server thread is the smallest set of instructions that can be managed independently. Because of multi-threading, this amount can be preconfigured to the amount of CPU cores times 4, of which a certain amount will remain idle at low load.They remain in an idle state with allocated memory, ready to be used by the Kopano Core server when needed.

Low idle threads (1 or 2) in combination with high RTT's can indicates slow performance due to thread locking.

In even higher input load situations, more threads (than the pre-configured amount) will be created because of a higher number of (queued) requests, which can also be a good indicator of an incident

CPU load

The CPU graph in kopano-stats shows the general overview CPU usage only by the kopano-server. It is not uncommon to see spikes at peak times, continuous spikes can indicate resource issues.

Sessions and users

These numbers show the connected users (normal as well as system). Since most clients create multiple parallel sessions, that number is shown as well, and can very from client to client. A high increase in sessions for a specific users could indicate an issue

Queue length and age

These numbers show the current queue length and age in time. Should these rise, the amount of kopano-server threads should be increased (with appropriate resources).

Kopano Core server threads

The number of kopano-server threads. this amount can be preconfigured to the amount of CPU cores times 4

Kopano Core server caches

For performace reasons, it is strongly recommended to set the cache settings of the Kopano Core server appropriate for your setup/server. Each time a request on an item can be found in the cache (cache hits), this avoids calls to other processes and disks/storage. Setting sensible cache settings certainly increases the performance.

This page contains some information about the settings and an example of a server dedicated for a complete Kopano Core suite. This page only covers cache settings for the Kopano Core server.

For more information about MySQL tuning, see MySQL tuning. If using the WebApp/Webaccess/Z-push in larger setups it is also advisable to tune your web server (Apache) as well, see Apache tuning.

In a server purely running Kopano Core, it is advisable to set caches to use around 80% (in total -- including MySQL) of the RAM available in your server and can be considered to be a rule-of-thumb. The other 20% should be free for system processes, other processes (like your MTA). (This does not take an optional webserver into account.) Whenever you set the values too high this can result in the use of swap on your server. Swapping should be avoided, but we do want to make use of the RAM available. Therefore these settings should be a healthy balance between the risk of swapping and efficient caching in memory.

One could use the following example values for the server in the dedicated server situation described above.

  • cell cache: around 25% of total RAM size
  • object cache: 16-64 MB
  • indexed object cache: 32-128 MB

These cache settings need to be configured in the /etc/kopano/server.cfg and details about these cache settings are described in the sections below.

The cache sizes set are a maximum and the actual use of it will grow along the server has had more request over time. Whenever you restart the server, these caches are purged and as a result performance will be lower until the caches are being filled up. To re-read configuration files, but not purge caches it is possible to reload the Kopano Core-server, instead of restarting it.

Cell cache (cache_cell_size)

Size in bytes of the cell cache. This is the main cache used in Kopano Core. It caches all data that comes into view in tables (e.g. the view of your inbox, or any other folder). In an ideal situation, all cells would be cached, so that the database does not need to be queried for data when browsing through folders, but this would require around 1.5K per message item (email, appointment task, etc) in the entire server. If you can afford it, set this value as high as possible.

Object cache (cache_object_size)

This caches objects and their respective hierarchy of folders. You can calculate the size with a simple calculation;

<concurrent users> * 100kb

Indexed object cache (cache_indexedobject_size)

This cache contains unique id's of objects. You can calculate the size with a simple calculation;

<concurrent users> * 512kb
  • No labels