server/usr/share/psa-pear/pear/docs/horde/PERFORMANCE

=========================
 Horde Performance Guide
=========================

:Contact: horde@lists.horde.org

.. contents:: Contents


Some tips on performance tuning systems for Horde.  This does not cover
hardware tuning or even low level system (network, filesystem, etc) tuning.

Don't apply the following tuning hints blindly.  Test your applications before
and after the changes under the conditions that are important for you.  For
some people it's more important to make them as fast as possible for a small
user base, others require the applications to scale well under a high load.
Some of these hints might even make the applications slower under certain
conditions or using a certain hardware.


Linux Tuning
============

* Recompile RPMS for your architecture (e.g. i586, i686, athlon, etc).
  This applies most to your Apache, PHP, IMAP, and POP3 packages.


Webserver/PHP tuning
====================

* Consider a PHP accelerator program.  See for example `The Zend Performance
  Suite`_, the `Alternative PHP Cache`_, eAccelerator_, or XCache_.  These
  accelerators speed up access by caching the compiled PHP code, eliminating
  the need to recompile the code for every single page load. **This is probably
  the easiest way to improve the performance of Horde**. See Autoloading_
  further down to get even more out of some of those accelerators.

* Enable PHP output compression in the Horde configuration. Do not enable
  compression in the PHP configuration (i.e. in ``php.ini``), because certain
  scripts don't work well with compression and Horde takes care of disabling
  compression conditionally.

* Keep the include path defined in ``php.ini`` as short as possible, with the
  most frequently used library paths first.  You don't need to include the
  local directory ``.`` because Horde always uses full paths instead of
  relative paths.

* Use an optimized ``php.ini``: start with ``php.ini-recommended`` in your PHP
  dsitribution.

* Don't run PHP session garbage collection too often if using a slow storage
  medium (like SQL). (See ``session.gc_probability`` in ``php.ini``)

* If you have a large number of sessions and are using PHP's default file
  based session handler, consider storing them in hashed directory levels.
  (See ``session.save_path`` at http://www.php.net/session)

* Consider using a faster storage medium for sessions, such as a tmpfs
  (if storing sessions locally) or memcache (for storing session information
  that can be accessed by multiple servers).

* Only load as many Apache and PHP extensions as needed (to reduce memory
  usage).

* Use statically compiled Apache modules, including the PHP module.

* Use compiler optimizations (--prefer-non-pic, -O3, -march -mcpu, -msse,
  -mmmx, -mfpmath=sse, etc.)

* If using SSL with a large site, consider a hardware SSL accelerator.

* Use shared memory for the Apache SSL cache if possible.

* To improve caching of static content if accessing Apache SSL with Internet
  Explorer, try setting longer expiration periods::

    ExpiresActive On
    ExpiresByType image/png "now plus 1 month"
    ExpiresByType image/gif "now plus 1 month"
    ExpiresByType text/javascript "now plus 1 month"
    ExpiresByType application/x-javascript "now plus 1 month"
    ExpiresByType text/css "now plus 1 month"

  .. Note:: You must compile the ``mod_expires`` extension into Apache in
            order to use these directives.

  .. Warning:: This might cause problems if you upgrade Horde and the users'
               browsers still use the old file versions.

* Disable DNS lookups in your Apache logging, or use a caching DNS server on
  the web server host.

  Horde itself will run DNS queries too, so make sure your DNS resolution works
  correctly and fast.

* Enable Apache keepalives.

* You can configure Horde to serve all images, style sheets and/or static
  javascript files from a different server. This could be a very lightweight
  server without PHP (and other CGI modules) builtin. If using SSL to serve
  all pages, the images/js server will also have to serve SSL content or else
  browsers will complain about non-secure content in a secure page. Since this
  server does not need to handle dynamic content, it would be wise to use a
  high-performance server with low memory and/or system resource requirements
  (this `IBM Article`_ can provide further information). You need to set
  the ``themesuri`` and/or ``jsuri`` parameters in ``config/registry.php`` for
  all applications and copy all ``themes`` and/or ``js`` directories in the
  same directory layout to the other server.

* Your webserver should use Expires headers to make sure static content can
  be cached on the user's browser.  For example, to make lighttpd set an
  expiration date on all graphics, javascript files, and stylesheets, add
  the following to ``lighttpd.conf``::

    $HTTP["url"] =~ "\.(jpg|gif|png|js|css)$" {
        expire.url = ( "" => "access 1 months" )
    }

* Enable caching in horde. Several applications make heavy use of caching and,
  if enabled, you will see a significant increase in performance.

* Enable caching/compression of javascript and CSS. See `Yahoo's Analysis`_
  which concludes that "[r]educing the number of HTTP requests has the biggest
  impact on reducing response time". Caching via filesystem is HIGHLY
  RECOMMENDED: it is also the only way of caching that reliably works on all
  browsers. Caching can also be done via horde caching, but the
  cache-busters used to generate unique URLs when the cached content changes
  do not work 100% reliably across all browsers.

* It is highly recommended to install the horde_lz4 package to activate
  compression for Horde data.  horde_lz4 is a minimal package that does
  real-time compression. On modern CPUs, this compression is as fast as an
  (unoptimized) memcpy action, making the compression essentially 'free' when
  compared to uncompressed data. horde_lz4 can be installed via PECL (see
  INSTALL for further details).

.. _`The Zend Performance Suite`: http://www.zend.com/horde.php
.. _`Alternative PHP Cache`: http://www.php.net/apc
.. _eAccelerator: http://eaccelerator.net/
.. _XCache: http://xcache.lighttpd.net/
.. _`IBM Article`: http://www.ibm.com/developerworks/web/library/wa-ltwebserv/
.. _`Yahoo's Analysis`: http://yuiblog.com/blog/2006/11/28/performance-research-part-1/


Sending Mail
============

* Generally using a local sendmail command to send mail will result in better
  peformance than using a SMTP connection.

* Some MTA servers may be faster or more efficient than others.  Consider
  switching to a faster format if needed.


PostgreSQL tuning
=================

* Do a ``VACUUM`` command periodically to tune your database.

* Increase ``shared_buffers`` and ``sort_mem`` memory settings.

* If web server and database is on the same unix host, use unix sockets
  instead of network connections for database access.


MySQL tuning
============

* If web server and database is on the same unix host, use unix sockets
  instead of network connections for database access.

* Enable mysql query cache if you have sufficient RAM.  Edit your ``my.cnf``
  file and add the following to the ``[mysqld]`` section (change the memory
  size to meet your needs)::

    set-variable = query_cache_size=128M


Horde tuning
============

Autoloading
-----------

* Horde automatically loads PHP source files on demand which relies on the PHP
  autoloading feature introduced with PHP 5 and the Horde Autoloader library.
  Both allow to limit the set of source code files pulled into the system to
  the minimal amount required to answer the current request. This saves memory
  and time but at the same time the Autoloader library has to map each class
  name to the path of the corresponding PHP file that holds the class
  definition. This procedure is expensive and can slow the system down.
  Fortunately the mapping is fixed unless files are added or removed which
  usually only happens during an upgrade.

  Thus Autoloading is amenable to caching and an easy way to improve the
  performance of the Horde Autoloader library, is to install the Autoloader
  Cache extension::

    pear install horde/horde_autoloader_cache

  This library is not installed by default because it will unconditionally use
  any of the following cache backends and does not allow for any further
  configuration: `Alternative PHP Cache`_, XCache_, eAccelerator_, or the local
  temporary filesystem.

  It also doesn't detect the rare case when the file paths of any PHP class in
  Horde changes. In this case you either need to use the provided script to
  empty the cache::

     horde-autoloader-cache-prune

  or empty the cache manually, e.g. by restarting the web server or deleting
  the cache file from the temporary directory.

VFS
---

* Try to avoid using a SQL backend for VFS. Many databases require binary data
  to be heavily escaped, resulting in storage sizes that are many times
  greater than the actual size of the data. File system VFS will normally
  provide much improved performance.


Application tuning
==================

* Some applications contain advanced features that might have a certain impact
  on the performance.  These features can usually be turned off in the
  application's configuration and are explicitly described as being a
  performance hit in the configuration web frontend.