9. Performance Tuning

When installing a Linux server with Kopano, it is imperative that MySQL is correctly configured to achieve maximum performance on the server; almost all performance bottlenecks are within the database access itself, so getting the SQL queries to run as quickly as possible is very important.

For large installations, it is strongly advised to tune Kopano’s cache parameters as well; These are normally set quite low to make sure that Kopano can run on relatively low-end servers, but in anything but the smallest installations, these defaults needs to be upped. Any installation with 50 or more users should definitely tune the cache parameters for maximum performance.

This document assumes the primary role of the server is to run Kopano. Always make sure that other factors are taken into account - for example an anti-spam system or a webserver running a site other than the Kopano WebApp.

There is also a more advanced tuning guide available to customers with a valid subscription. Please create a ticket with the Kopano support to retrieve it.

9.1. Hardware Considerations

There are also various different hardware setups to consider when setting up a server for Kopano. We will discuss the various types of hardware that affect performance.

9.1.1. Memory usage

Tuning memory usage is one of the best ways of increasing server performance; as RAM is generally cheap, using a large amount of RAM in the server properly can boost performance by orders of magnitude.

On the other hand, setting RAM usage too high may cause the server to swap out parts of the memory which need to be swapped back in later, causing a large slowdown in all parts of the server. It is therefore important to set the RAM usage of various components to a high enough setting to use the RAM available, and at the same time not to set the RAM usage too high.

To make use of the available RAM as best as possible, Kopano is designed to use only a fixed amount of physical RAM; the memory usage does increase per user that connects, but only by a small amount - the largest part of the memory usage is due to cache settings in the configuration file. This makes it very easy to control the exact amount of memory that will be used in a live situation, and one can be pretty sure that the actual amount of RAM used will never go far beyond the values set.

So, in general, the optimum RAM usage is as high as possible, without making the system needing to swap out important parts of available memory.

It is very difficult to give a fixed value for what the optimal memory usage distribution is for a given server, as data access patterns vary wildly from server to server. We will describe some rule-of-thumb parameters here and make the RAM usage patterns as clear as possible here.

9.1.2. Hardware considerations

In servers running Kopano, the main performance bottleneck will be the route between the data on the hard disk, and the time it takes to get to the client. This means that generally, I/O performance is more important than CPU performance. Using this as a basis, the following pointers may help in selecting the correct hardware for the system:

9.1.3. More Memory is More Speed

More RAM means better caching and therefore better speed.

Kopano is specifically designed to make use of the large amounts of RAM that is available in modern servers. On the other hand, please remember that in normal Linux server the maximum amount of usable RAM in a 32-bit server is 3Gb unless PAE (physical address extension) is supported in the kernel, CPU and mainboard. If more than 3Gb is needed without some sort of limitation, use a 64 bit system, a 64 bit Linux OS, and a 64 bit Kopano package.

9.1.4. RAID 1/10 is faster than RAID 5

In general, a RAID1 or RAID10 array is faster at database accesses than RAID5 and RAID6. Kopano strongly recommends not use the RAID5 or RAID6 configuration to prevent performance issues.

9.1.5. High rotation speed (RPMs) for better database performance

High-end SCSI or SAS disks regularly have high rotation speeds of 10K or even 15K RPMs. The rotation speed of the disks affects seek times on the disk. Although the Kopano database format is optimized to have data available on the disk in a serial fashion, and most reads are done fairly localized on the disk, seek time is still a large speed factor for I/O. The higher the rotation speed, the lower the seek time.

9.1.6. Hardware RAID

Hardware RAID controllers often have large amounts of cache RAM. This can also increase performance and data throughput of the I/O subsystem. If a hardware RAID controller is used however, always make sure that either write-back cache is not used, or a functioning UPS and shutdown process for the server are available, as write-cached data will be lost when the power fails. This is not only harmful for the data that was written at that moment, the write could actually corrupt the on-disk innodb data.

9.2. Memory Usage setup

There are basically 4 large parts of the server setup that use server memory:

  • Kopano’s cell cache (caches individual cell data within a table view)
  • MySQL’s buffer size (caches reads and writes from the ibdata file)
  • MySQL’s query cache (caches exactly repeated SQL queries)

In a server purely running Kopano, make sure these caches are setup to use around 80% of the RAM in the server. The other 20% should be free for system processes, other processes (like MTA) and the webserver.

For a general rule-of-thumb, the following RAM distribution should be used:

Kopano caches:

  • cache_cell_size: around 25% of total RAM size
  • cache_object_size: about 100kb per user
  • cache_indexedobject_size: about 512kb per user

These cache settings need to be configured in the /etc/kopano/server.cfg file. To activate the cache size changes the Kopano Server need to be restarted.

MySQL settings:

  • innodb_buffer_pool_size: around 50% of total RAM size
  • mysql_query_cache: 32Mb
  • innodb_log_file_size: 25% of the innodb_buffer_pool_size
  • innodb_log_buffer_size: 32M
  • innodb_file_per_table: 1
  • max_allowed_packet: 16M
  • table_cache: 1000

These settings need to be configured in the /etc/my.cnf or /etc/mysql/my.cnf file below the [mysqld] section.

It’s recommended to change these MySQL settings before starting the Kopano Server and migrating user data.

The most important settings will now shortly be described to illustrate the need of each of these cache settings.

9.2.1. Kopano’s Cell Cache (cache_cell_size)

Data that is actually shown to the user in table views, passes through the cell cache. This means that any view of a table in Outlook will only retrieve the information from the database of the cells that are not already in the cache. The cache lifetime is as long as the entire server lifetime, so opening an inbox twice in succession should result in 0 disk accesses for the second access. It is a good idea to set the cell cache as high as can be managed, usually about the same size as the MySQL buffer size.

9.2.2. Kopano’s object cache (cache_object_size)

The Kopano object cache is used to cache the hierarchy table. Each object that is accessed will be placed in this cache, making it faster to retrieve the information again without accessing the database. The more items users have in their folders, the more important this cache becomes. Since the information is quite small, this cache does not need to be large. About 1Mb for 10 users is even an overestimation.

9.2.3. Kopano’s indexedobject cache (cache_indexedobject_size)

To open a specific item, the program needs to send the server a unique key, called an entryid, to the server to request that item. This cache is a 2 way index of the MAPI key to a database key and the other way around. The translation of the keys are quite important. This cache is filled per folder, so large folders will push out otherwise important information. Normal usage is about 0.5 Mb per user.

9.2.4. MySQL innodb_buffer_pool_size

The MySQL buffer is used to cache reads and writes to the ibdata file. In a dedicated MySQL machine, this would be anywhere between 50% to 80% of the physical RAM size in the machine. When MySQL is run on the same machine as Kopano, it is recommended to be around 25% of physical RAM size (so that Kopano’s Cell Cache can also be set to this value)

9.2.5. MySQL innodb_log_file_size

The innodb_log_file_size is the size of the transaction log. By default there are two logfiles. The preferred value size for the innodb_log_file_size is 25% of the innodb_buffer_pool_size.

9.2.6. MySQL innodb_log_buffer_size

The size of the innodb_log_buffer_size that InnoDB uses to write to the log files on disk. A large log buffer allows large transactions to run without a need to write the log to disk before the transactions commit. If big transactions are present, making the log buffer larger will save disk I/O. This value should be 25% of the innodb_log_file_size.

9.2.7. MySQL query_cache_size

The MySQL query cache is normally disabled. Enabling the query cache can cause a small performance increase, but increasing it to more than a few MBs is not necessary as most recurring SQL queries are rather small.

9.2.8. MySQL innodb_file_per_table

The innodb_file_per_table option will create per database table a innodb data file, instead of using one large ibdata file for all data. Having a file per table will give more flexibility to move tables to different filesystem partitions for better performance.

9.2.9. MySQL max_allowed_packet

The max_allowed_packet defines the maximum size of a single packet which can be inserted in the database. Customer changing this value to a higher value, should keep in mind the Outlook offline database is also using MySQL, which can cause client issues in case packets are larger than 16Mb.

9.3. Setup of modules on different servers

There are several parts of the Kopano server that can be hosted on different servers. In fact, almost each part of the server can be run on a different system. However, in practice, splitting all modules of the server on the different servers, will not increase performance. The main parts that should be considered are:

  • Server1: MySQL server
  • Server2: Kopano server
  • Server3: MTA + AntiSpam/AntiVirus
  • Server4: WebServer

If these 4 parts were to be hosted on 4 servers, each server would communicate with the others to work as a single system. This setup can be made quite easily simply by configuring the various parts of the system to communicate with another server.

For the MySQL server, this only has to be accessed by the kopano-server process on Server2. This can very easily be done by setting the correct login and host configuration in Kopano’s server.cfg.

The Kopano Server will itself be contacted by Outlook Clients, Server3 (MTA), and Server4 (WebServer). This can be done because the kopano-server process is listening on port 236 on Server2, and the other servers can connect with it.

Server3 will accept email on port 25 or fetch email via some email protocol like POP3. After passing the email through anti-spam and anti-virus, the email will be passed to the kopano-dagent process. The kopano-dagent process can be configured to connect with an SSL certificate with Server2. This SSL certificate is required because the kopano-dagent needs to be authenticated because it is connecting from a different server over port 236. When this is configured in both Server3 and Server2, the email can be delivered directly to Server2 by Server3.

Server4 is the WebApp server, running Apache, and accepting connections on port 80 (or 443 for SSL). The Kopano WebApp can be configured (in config.php) to connect over port 236 (or port 237 for SSL) to Server2 for the actual data. Once this has been configured, this server is ready to serve users. No additional configuration is required.