It’s all in a day’s work

My main home server is a measly pentium II class machine running (now) on Debian Etch. Not the fastest machine but it works, uses little power and is cheap while setup from left-overs. Among other things it serves me my email when not at home using RoundCube Webmail. With the low-end hardware I am using it is key to keep it as fast and lightweight as possible. The server is behind a DSL connection at home so compression comes in handy as well.
Read the rest of this entry »

Seems I just made a post 1 hour into the future and with that, on a different day. The Wordpress settings say

Unfortunately, you have to manually update this for Daylight Savings Time. Lame, we know, but will be fixed in the future.

Lame indeed, and guess I forgot about this. A while ago a colleague encountered a similar problem in phpBB. Guess it’s PHP related and not just Wordpress, as both products have the same problem. I wonder if the fix promised by Wordpress is waiting for daylight savings time to be abandoned as idea, since it’s advantages are still being questioned.

With high traffic sites, performance issue’s rise. Now one of the solutions is to use an opcode caching mechanism for PHP. There are two mainstream open source solutions for that, APC and eAccelerator. And there is Zend platform and Zend core.

Installing eAccelerator
I found a very straight forward howto about installing eAccelerator (and others) on Debian.

But, as always, there are some problems with that tutorial. First the -- is replaced by a special character on that tutorial (and in my blog if I don’t use the <code> tag) in the configure command, so that doesn’t work if you copy paste it. The working configure command is:


./configure --enable-eaccelerator=shared --with-php-config=/usr/bin/php-config


And you don’t need to do all the work as root, only the apt-get, the make install and the php.ini editing should be done as root (best practice, only use root privileges when needed).

Also the double quotes are changed into a special character in that tutorial, so if you get an error in your logs about unable to load \xe2\x80\x9deaccelerator.so\xe2\x80\x9d you copied them just like I did

This is what I put in the php.ini, without the special double quotes, and with one change


extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"


The tutorial writer creates the cache directory in /tmp. But he fails to make the remark that /tmp is cleared on server restart. So that’s not really a good option. So I’ve done the following in stead


sudo mkdir /var/cache/eaccelerator
sudo chown www-data /var/cache/eaccelerator
sudo chmod 0755 /var/cache/eaccelerator


Yes, the 0644 from the eAccelerator wiki is what you want for the files being created in there, but not for the directory itself.

The big disadvantage of this way of installing it, is that you probably need to recompile it (after a make clean) and reinstall it on every update of PHP. But reading up on APC vs eAccelerator made me choose for the latter.

But does it really help?
Now, the results. What better to test then my own PHP blog (and yes it’s not the fastest one, it’s running on a VPS).

Before installing eAccelerator:

Server Software:        Apache/2.2.8
Server Hostname:        blog.delgurth.com
Server Port:            80

Document Path:          /
Document Length:        44436 bytes

Concurrency Level:      10
Time taken for tests:   397.121299 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      44796000 bytes
HTML transferred:       44436000 bytes
Requests per second:    2.52 [#/sec] (mean)
Time per request:       3971.213 [ms] (mean)
Time per request:       397.121 [ms] (mean, across all concurrent requests)
Transfer rate:          110.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       6
Processing:   712 3961 1674.7   3696   10696
Waiting:      368 2177 1013.3   2033    6943
Total:        712 3961 1674.7   3696   10696

Percentage of the requests served within a certain time (ms)
  50%   3696
  66%   4454
  75%   4977
  80%   5270
  90%   6225
  95%   7039
  98%   8188
  99%   8632
 100%  10696 (longest request)

After installing eAccelerator

Server Software:        Apache/2.2.8
Server Hostname:        blog.delgurth.com
Server Port:            80

Document Path:          /
Document Length:        44436 bytes

Concurrency Level:      10
Time taken for tests:   242.584585 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      44796000 bytes
HTML transferred:       44436000 bytes
Requests per second:    4.12 [#/sec] (mean)
Time per request:       2425.846 [ms] (mean)
Time per request:       242.585 [ms] (mean, across all concurrent requests)
Transfer rate:          180.33 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       4
Processing:   430 2419 983.2   2330    6409
Waiting:      100  648 448.6    578    3025
Total:        430 2419 983.2   2330    6409

Percentage of the requests served within a certain time (ms)
  50%   2330
  66%   2798
  75%   3051
  80%   3246
  90%   3712
  95%   4182
  98%   4614
  99%   4901
 100%   6409 (longest request)

So it helps also quite a bit on my wordpress install, it’s about a 33% performance increase!

Some material I read

• Some benchmarks of opcode caches (in german)
• Some performance tips with some more reading material
• A benchmark on APC vs eAccelerator on Drupal
• A benchmark on APC vs eAccelerator vs XCache on Drupal
• Another benchmark and an explanation about the differences between APC and eAccelerator

P.s. yet another wordpress rant, if you have empty lines between <code> tags, wordpress inserts <p> tags there for you. Not very nice to my liking, since it breaks the formatting of the <code> tag, which I used to format the apache bench results…