Geeklog is a popular and very flexible and secure weblog package written in PHP. While flexible, and going a long way towards a full content management system, Geeklog is also big, feature rich, and leaves some things to desire when it comes to performance. In this article I explain some of the things I did to optimize my FreeBSD/Apache2/PHP4 based Geeklog installation.

There are quite some things you can do to make your Geeklog server perform better, and in some cases, a lot better.

The following components play a big role in the performance of your Geeklog installation:

• Server hardware
• MySQL
• http server (assumed Apache)
• PHP extentions and Zend cache
• Did I mention MySQL yet?

A pIII 600 or better should do for a decent size site, given it has at least 512MB ram.

RAM is going to be the most important thing because no matter how fast your CPU, not having to really run a query because the result is cached is always going to be faster.

Having dedicated disks (optionally with striping or raid) for your database storage is ideal, but at the very least your disk subsystem should be fast. It is a large factor in the performance of your database.

More RAM can partially overcome a slower disk subsystem.

As mentioned earlier, I run FreeBSD on my server. Some of the details in the remainder of this article may be FreeBSD specific, and where I am aware of that I will say so. Most of it should apply to any modern Unix variation running Apache 2 and a fairly modern PHP 4 version.

Due to the way MySQL and Geeklog interact (not so nicely.. Geeklog uses mostly generic sql on its path to supporting other databases) it helps a lot to reserve extra memory for MySQL's query cache. While it doesn't help much for posting, it will take quite a bit of load from the database while people are browsing the site.

If you happen to have a SMP machine, you may have to recompile MySQL in order to get proper SMP support from it. Also make sure to check the example MySQL configuration files for managing the number of threads MySQL will use.

On FreeBSD 3.x and 4.x you will need to install the linux-threads port if you want MySQL to take advantage of the SMP capabilities. On FreeBSD 5 you can either use the linuxthreads port or process-scope (freebsd native) threads. It looks like linux-threads are better supported tho.
When running Linux, make sure you run a 2.6.x kernel.
To get linuxthreads on FreeBSD:

  cd /usr/ports/devel/linuxthreads
  make install
  cd /usr/ports/databases/mysql40-server
  make WITH_LINUXTHREADS=yes BUILD_OPTIMIZED=yes BUILD_STATIC=yes install

When running FreeBSD 5.2 , you should try process scope threads instead unless you already use linuxthreads for other things.

To build the port with process scope threads:

  cd /usr/ports/database/mysql40-server
  make WITH_PROC_SCOPE_PTH=yes BUILD_OPTIMIZED=yes BUILD_STATIC=yes install

In either case MySQL should make use of the extra CPUs that you have.

Additional information regarding MySQL and multi-threading can be found at Jeremy's weblog

MySQL depends a lot on your hardware for performance. Fast disks and lots of memory for caching will make it shine despite the fact that Geeklog's sql is far from optimized for MySQL.

The way in which SMP may help most is by giving more time to the webserver to let PHP do its work also.

To get more performance out of PHP, there are a few ways to go.

• Install pear and pear-APC
• Install Turck-mmcache
• Install a Zend cache

I get by far the best results by installing the somewhat experimental Turck-mmcache package instead of the commercial Zend-cache, and it seems to do its job very well.

Pear and APC caused some trouble for Apache and it wouldn't shutdown properly, instead going in an infinite loop somewhere.

To install it on FreeBSD:

  cd /usr/ports/www/turck-mmcache
  make install

And follow the instructions at the end of the installation to update your php.ini file.

You can install php in a few ways, what is important is that you have Apache 2 installed already and have WITH_APACHE2 in your /etc/make.conf file. For the rest its a matter of what you need, there is no substantial performance difference between the different ways to install php. The main reason for wanting the 'master' package would be because you also want to use PHP in shell scripts (for Geeklog's storymail feature for example)

Ideally, you would have two separate webservers, one for static content and one for PHP.

This would be ideal because static content and PHP require almost opposite tuning parameters for optimal performance.

This is in fact possible with FreeBSD, even if you have only one machine and a single public IP.

For this, FreeBSD's jail feature could be used to provide entirely separate environments for the two webservers. They can communicate using private IP addresses because only one of them needs to be visible to the outside world, the static content server. The PHP server will be called by the 'frontend' server using mod_proxy.

Ideally, the frontend server is configured with the worker MPM, mod_proxy, mod_proxy_http and any other modules you need there.

You want the worker MPM because it seems it offers better performance and resource usage with mod_proxy. It also seems that the worker MPM has problems with mod_php4 on FreeBSD at least, so you shouldn't have mod_php support installed, besides, that is what we are going to use the backend server for.

This server should be configured to support keep-alive and to make 'children' last as long as possible. Memory usage of this server will be relatively low, depending mostly on the settings you are going to make for the mem_cache module.

For the backend server, you want the prefork MPM because of the reason explained above.

KeepAlive should be turned off on the backend server and MaxRequestsPerChild should be set fairly low. MaxClients should also be kept relatively low, its value will in the end play a large factor in connections used for your database and memory usage on the backend server.

Get Geeklog from the Geeklog website instead of using the port. At this moment, the port is outdated, and your really want the latest updates from Geeklog for some relevant bugfixes.

Next time, installing and configuring the jails for our server.