Product SiteDocumentation Site

Chapter 9. Performance Tuning

9.1. Hardware Considerations
9.1.1. Memory usage
9.1.2. Hardware considerations
9.1.3. More Memory is More Speed
9.1.4. RAID 1/10 is faster than RAID 5
9.1.5. High rotation speed (RPMs) for better database performance
9.1.6. Hardware RAID
9.2. Memory Usage setup
9.2.1. Zarafa’s Cell Cache (cache_cell_size)
9.2.2. Zarafa’s object cache (cache_object_size)
9.2.3. Zarafa’s indexedobject cache (cache_indexedobject_size)
9.2.4. MySQL innodb_buffer_pool_size
9.2.5. MySQL innodb_log_file_size
9.2.6. MySQL innodb_log_buffer_size
9.2.7. MySQL query_cache_size
9.2.8. MySQL innodb_file_per_table
9.2.9. MySQL max_allowed_packet
9.3. Setup of modules on different servers
When installing a Linux server with Zarafa, 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 Zarafa’s cache parameters as well; These are normally set quite low to make sure that Zarafa 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 Zarafa. 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 Zarafa WebAccess.
More information about performance tuning can also be found on

9.1. Hardware Considerations

There are also various different hardware setups to consider when setting up a server for Zarafa. 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, Zarafa 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 Zarafa, 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.
Zarafa 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 Zarafa 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. Zarafa 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 Zarafa 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.