The idea consists of these basic prerequisites:
- sometimes I need to create small application that is not a standard web application,
- it could be necessary that it it running as root/other privileged user,
- it probably receives client connections from network,
- I need to have total control of what it does, for security reasons,
- I do not want to configure it, I want to write it.
- I want it to be written in PHP, which is a commodity language.

Usually PHP is coupled with some web server software, which together then constitutes web application server. This is a standard setup. It involves installing a web server, like Apache or NginX or IIS etc, which then you have to configure to suit your needs. Then you have to add PHP to it, and configure that too.

But what if you do not want a WEB server, what if you want a CUSTOM application server that does not use HTTP protocol but some weird/invented/forgotten/X protocol that you find suitable for your purpose?

This is why I have written this framework. You do not have to start from scratch, if you do not want to. What it does is this:
- starts and daemonizes
- forks as many children as needed
- children start waiting for connections
- when connection arrives, one of the children accepts the connection
- here your custom processing part starts – you start by rewriting the $this->worker_handleClient() or $this->worker_handleRequest() method, like below:

class AppSrvDemo extends A2o_AppSrv
{
  protected function worker_handleClient ($clientSocket, $clientIp, $clientPort)
  {
   // You can do some socket reading here
   $message = "Hello, Client!\n";
   socket_write($clientSocket, $message, strlen($message));
   $this->worker_closeConnection();
  }
}

And that is basically it. Framework handles the rest of the story, accepts multiple simultaneous connections, forks additional children, etc. There is still a lot to do but I managed to get first working daemon written in 10 minutes. It does fairly trivial job (accepting XML-RPC request and then su-ing to some specified user and running some shell command) but what seemed miles away once is now easily achieved.

If you need it, enjoy it. Here is the URI:
Standalone preforking PHP application server framework.

If you find some feature missing and/or you have prepared a patch for it, let me know in comments. Also, (constructive) critique is welcome.

A year ago I was working on a website project which used PHP as a language of choice. The project development resulted in quite large amount of PHP code. After a brief research we decided that organising our code the way Zend Framework is organized is our way to go. While ZF’s naming conventions are a nice and effective way to autoload classes and avoid naming conflicts, it is still a bit cumbersome at coding stage (long class names).

At that time I had my first glance at PHP 5.3 feature list and namespaces seemed a good step forward from current practice. Unfortunately stable PHP 5.3 release was far from being released so I had to dump the namespace idea for that particular project. But I decided to migrate to PHP 5.3 as soon as possible.

Another part of the story is server administration. On all the servers I manage I utilise PHP opcode caching. Currently I use eAccelerator and I am satisfied with it’s performance and stability. But eAccelerator’s website (at the moment of this writing) states nothing about PHP 5.3 support. Therefore I was forced to look elsewhere.

Many websites recommend APC with the suggestion that it is being actively maintained, unlike some other opcode caches. I remember back in year 2004 when I was testing it and comparing it to Turck MM cache that its performance sucked. Unfortunately I have no evidence to support my claim, but it is also irrelevant in 2009. Yet “actively maintained” phrase implies hope that APC supports PHP 5.3. And its changelog confirms it.

First stable PHP 5.3 version was released last week and I was psyched to at least test it, but I did not want to be held back by an opcode caching solution, so I decided to compare eAccelerator and APC again. If APC performs as well as eAccelerator does (both on PHP 5.2.9), then I will seriously consider migration to PHP 5.3 and migration from eAccelerator to APC.

Goal

There is a single question to be answered: how does APC perform in comparison to eAccelerator on PHP 5.2.9?

System setup

I used exactly the same system with Apache web server as it is described in this article. I only conducted “Application frontpage” test as it is the only relevant testcase.

I installed APC with the following command

printf “no\n” | /usr/local/httpd/php/bin/pecl install apc

and only enabled it in php.ini by adding

extension=”apc.so”

and removing eAccelerator, with no additional configuration.

Why not PHP 5.3.0 or PHP 5.2.10?

• PHP 5.3.0: simply because I have not yet tested it and upgraded the systems I manage.
• PHP 5.2.10: simply because I tried to upgrade but the release is buggy.

Results

eAccellerator vs APC: application frontpage

Analysis of results and conclusion

Performance results for both opcode cache solutions are almost identical, difference is negligible. Results at concurrency level higher than 128 are not reliable, I am in a phase of fixing that anomaly. From this test I can conclude that performance-wise you can safely choose any of these two opcode cache solutions.

Stability

I can not comment on the stability of APC more than that I have had no problems with it for this short period of testing time. I have no stability (segfault) problems with eAccelerator in the production environments.

Info/status/control script

What I DO miss with APC is a simple control.php which eAccelerator provides. It gives you an overview of caching statistics.
Update (2009-12-01): Henrik Olsen notified me that APC also includes control script which provides an overview of caching statistics. See comments below for an URI of his article where he demonstrates the subject.

Update

As of today (2009-07-07) the compile results of eAccelerator and APC with PHP 5.3.0 are as follows:

• eAccelerator v0.9.5.3 – does not compile
• APC stable v3.0.19 – does not compile
• APC beta v 3.1.2 – compiles OK, but with some warnings about “–enable-spinlocks” being unrecognised and warning: passing argument 1 of ‘zval_isref_p’ discards qualifiers from pointer target type

Test methodology

All the software was compiled from source (details below). Benchmarks were conducted using ApacheBench tool (ab) from apache installation. The tool was running on the same machine as the server. Both servers had request logging disabled. Tests were conducted once with keepalive feature enabled and once with keepalive disabled. Each test was repeated five times and average taken. Test files were:

• HelloWorld.php – short php scripts, which only echoes string “Hello, World!” (13 bytes), intended to measure processing overhead of PHP vs static file (contents of this file are here: ‘
• HelloWorld.txt – a static file with string “Hello, World!” inside (also 13 bytes), intended to show static file serving overhead
• 100KB.txt – a static 100KB file
• 1MB.txt – static 1MB file
• index.php – a frontpage of certain application which is quite CPU intensive and includes PHP processing, some DB querying, file cache reads and HTML template processing

Test system and ./configure commands

• Hardware: HP DL380 G5
• Hardware: 2x Intel Xeon E5420 (4 cores each, total of 8 cores)
• Hardware: 8GB of ECC RAM
• Hardware: Smart Array P400i RAID-1 with 2x 147GB SAS drives
• OS: Slackware 12.2 with almost all software compiled from source
• Filesystem: ext3
• Apache version: 2.2.11, php via mod_php
• Nginx version: 0.7.59, php via request proxying to php-fpm (via socket)
• PHP version: 5.2.9
• Eaccelerator version: 0.9.5.3 (for both, Apache and Nginx)
• MySQL version: 5.0.77
• OpenSSL version: 0.9.8k
• both servers had request logging disabled

Configure command for Apache:

./configure –prefix=/usr/local/$PDESTDIR_HTTPD –sysconfdir=/etc/httpd \
–enable-authn-file –enable-authn-default \
–enable-authz-host –disable-authz-groupfile –enable-authz-user –enable-authz-default \
–enable-auth-basic \
–disable-include –disable-filter –disable-charset-lite \
–enable-log-config \
–enable-env –enable-setenvif \
–enable-ssl –with-ssl=/usr/local/openssl-$PVERSION_OPENSSL \
–enable-http –enable-mime –enable-status \
–disable-autoindex –disable-asis \
–enable-info \
–enable-cgi –disable-cgid \
–enable-vhost-alias \
–disable-negotiation \
–enable-dir \
–disable-actions \
–disable-userdir \
–enable-info \
–enable-rewrite \
–enable-so \
–with-mpm=prefork

Configure command for Nginx:

./configure –prefix=/usr/local/$PDIR \
–conf-path=/etc/nginx/nginx.conf \
–error-log-path=/var/log/nginx/nginx_error.log \
–pid-path=/var/run/nginx.pid \
–lock-path=/var/run/nginx.lock \
–user=httpd \
–group=httpd \
–with-openssl=/usr/local/openssl-0.9.8k

Configure command for PHP:

—–[These lines are for PHP with Apache (mod_php)]—————-
./configure –prefix=/usr/local/$PDESTDIR_HTTPD/$PDIR \
–with-apxs2=/usr/local/$PDESTDIR_HTTPD/bin/apxs –enable-cli –enable-cgi \
–with-config-file-path=/etc/php/httpd \

—–[These lines are for PHP with Nginx (php-fpm)]—————-
./configure –prefix=/usr/local/php-fpm \
–enable-cli –enable-fastcgi –enable-fpm \
–with-fpm-conf=/etc/php/php-fpm/php-fpm.conf \
–with-fpm-log=/var/log/php-fpm.log \
–with-fpm-pid=/var/run/php-fpm.pid \
–with-config-file-path=/etc/php/php-fpm \

—–[These lines are common for both]—————-
–disable-short-tags \
–disable-ipv6 \
–disable-all \
\
–enable-libxml \
–with-openssl=/usr/local/openssl-$PVERSION_OPENSSL \
–with-pcre-regex \
–with-zlib \
–with-bz2 \
–with-curl –with-curlwrappers \
–enable-dba=shared –with-db4 –enable-inifile –enable-flatfile \
–enable-dom –with-libxml-dir \
–enable-filter \
–enable-ftp \
–with-gd –with-jpeg-dir –with-png-dir –with-freetype-dir \
–with-gettext \
–enable-hash –with-mcrypt \
–with-iconv=/usr/local/lib –with-iconv-dir=/usr/local/lib \
–with-imap=/usr/local/imap-$PVERSION_CYRUSIMAP –with-imap-ssl \
–enable-json \
–enable-mbstring –enable-mbregex –enable-mbregex-backtrack \
–with-mysql=/usr/local/mysql-$PVERSION_MYSQL –with-mysqli=/usr/local/mysql-$PVERSION_MYSQL/bin/mysql_config \
–enable-pdo –with-pdo-mysql=/usr/local/mysql-$PVERSION_MYSQL –with-pdo-sqlite –enable-sqlite-utf8 \
–enable-reflection \
–enable-session –with-mm \
–enable-shmop \
–enable-simplexml \
–enable-soap \
–enable-sockets \
–enable-spl \
–with-regex \
–enable-sysvmsg –enable-sysvsem –enable-sysvshm \
–enable-tokenizer \
–enable-xml –enable-xmlreader –with-xmlrpc –enable-xmlwriter –with-xsl \
–enable-zip \
\
–with-pear \
–enable-zend-multibyte

Runtime configuration files

Apache+mod_php: httpd.conf
Apache+mod_php: php.ini
Nginx+php-fpm: nginx.conf
Nginx+php-fpm: php-fpm.conf
Nginx+php-fpm: php.ini was functionally identical to the php.ini used by Apache+mod_php

Results

HelloWorld.php results:

Apache VS Nginx: HelloWorld.php

 
HelloWorld.txt results:

Apache VS Nginx: HelloWorld.txt

 
100KB.txt results:

Apache VS Nginx: 100KB.txt

 
1MB.txt results:

Apache VS Nginx: 1MB.txt

 
Custom real world application performance comparison results:

PHP application benchmark Apache+mod_php vs Nginx+php-fpm

 
Apache HelloWorld.php VS HelloWorld.txt comparison results:

Apache VS Nginx: Apache PHP vs TXT

 
Nginx HelloWorld.php VS HelloWorld.txt comparison results:

Apache VS Nginx: Nginx PHP vs TXT

Memory footprint

If memory usage is of real importance to you, then you should seriously consider using Nginx. With nginx all the static file serving capabilities can be achieved by using only that many worker processes as there are CPU cores on your server. In the example above this means 8 cores and 8 worker processes for Nginx, no matter how many clients connect to it simultaneously. For PHP, there are 16 php-fpm workers alive in the example above (which is enought if you are not doing some blocking IO). When you sum this up you get a decently low memory usage.

On the other hand Apache (with prefork MPM, which is required by mod_php) creates as many processes as there are clients (up to the limit of MaxClients directive) and it does not matter whether clients are requesting static files or for PHP applications. So for 200 clients it will create 200 processes with embedded PHP, which gives far larger memory footprint than Nginx has.

Conclusion or “should you switch from one to another?”

Short answer: I do not know.
Longer answers are here:

1. If you host many websites and users utilise .htaccess files and change them frequently, then the answer is probably “no”. The cost of switching over to Nginx and converting all the configuration to new format usually reaches the cost of buying another server.
2. If you have single application on multiple servers and most of the processing power is not consumed by serving static file content, the answer is also probably “no”.
3. If you are mainly serving static content, the answer is obviously “yes”.
4. If you are creating a fresh system for webhosting solution, the answer is probably “yes”, with the assumption that users will not miss the .htaccess functionality or it will be provided by other means
5. If you are consolidating services with some virtualization technology, then answer is probably “yes”, as Nginx tends to have smaller memory footprint than Apache.
6. If you are looking towards Nginx as your PHP server optimization, look again, but not at Nginx, at your application code.

I hope that this comparison helps you with your decision. If you have some questions, feel free to email me or post a comment below.

UPDATE 2009-06-25:
The ApacheBench tool was invoked with the following command:

ab -n NREQ -c NCONC [-k] http://server.domain.com/bench/FileName
NREQ is the number of requests:
- HelloWorld.php: 500000
- HelloWorld.txt: 500000
- 100KB.txt: 500000
- 1MB.txt: 50000
- AppFront: 5000
NCONC is the number of concurrent requests, as noted in the graphs.

Each test was repeaded 5 times and the average was calculated.
Thanks to Sean Osh for requesting this info.

HP DL360 G4 server

HP and its line of DL servers is very respected amongst IT engineers. It is (at least by my experience) a reliable class of servers, well built, easy to maintain and comes with an excellent server management software called Integrated Lights-Out (ILO). DLs SCSI and SAS storage subsystem is usually controlled by controllers called Smart Array, which can be integrated onto the motherboard or not. Fresh HP customer gets all the nifty RAID levels to play with and is usually satisfied. But what fresh customer usually DOES NOT KNOW is that Smart Array write performance really sucks if write cache is not enabled. And to enable it, fresh user needs to install a special module with attached battery called BBWC. So, HP, if you are accidentally reading this, please do notify your customers about such things.

HP DL380 G5 server

This is another server where I conducted the benchmark and, unlike DL360 G4, already came with BBWC installed. To simulate absence of write cache I disabled it with command line tool hpacucli (HP Array Configuration Utility Command Line Interface).

Benchmark metodology

For this benchmark I used two tools from sql-bench suite which heavily stress filesystem with lots of file creations and deletions. These tools are test-alter-table and test-create. The former test is faster and only gives rough figure. The later creates and deletes around 50,000 MyISAM tables which results in 150,000 files created and deleted. I executed both benchmarks first without and then with write cache enabled.
One of the machines (the DL380) was already in production, but it was benchmarked during the night when usage is negligible.

Test systems

HP DL360 G4

• Controller: Smart Array 6i
• Filesystem: ufs
• OS: FreeBSD 6.0
• MySQL: mysql-5.0.41-freebsd6.0-i386

HP DL380 G5

• Controller: Smart Array P400i
• ext3 filesystem
• OS: Slackware 12.2
• MySQL: mysql-5.0.77 compiled from source

Results on HP DL380 G5

Drive write cache DISABLED

Testing of ALTER TABLE
Time for insert (1000) 0 wallclock secs
( 0.02 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Time for alter_table_add (100): 17 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for create_index (8): 2 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for drop_index (8): 2 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for alter_table_drop (91): 16 wallclock secs ( 0.01 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.01 CPU)
Total time: 37 wallclock secs ( 0.03 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.03 CPU)

Testing the speed of creating and dropping tables
Time for create_MANY_tables (10000): 253 wallclock secs ( 0.26 usr 0.06 sys + 0.00 cusr 0.00 csys = 0.32 CPU)
Time to select_group_when_MANY_tables (10000): 1 wallclock secs ( 0.09 usr 0.07 sys + 0.00 cusr 0.00 csys = 0.16 CPU)
Time for drop_table_when_MANY_tables (10000): 1 wallclock secs ( 0.09 usr 0.03 sys + 0.00 cusr 0.00 csys = 0.12 CPU)
Time for create+drop (10000): 259 wallclock secs ( 0.24 usr 0.18 sys + 0.00 cusr 0.00 csys = 0.42 CPU)
Time for create_key+drop (10000): 255 wallclock secs ( 0.41 usr 0.11 sys + 0.00 cusr 0.00 csys = 0.52 CPU)
Total time: 769 wallclock secs ( 1.09 usr 0.45 sys + 0.00 cusr 0.00 csys = 1.54 CPU)

Drive write cache ENABLED

Testing of ALTER TABLE
Time for insert (1000) 0 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Time for alter_table_add (100): 3 wallclock secs ( 0.01 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Time for create_index (8): 1 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for drop_index (8): 0 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for alter_table_drop (91): 4 wallclock secs ( 0.01 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.01 CPU)
Total time: 8 wallclock secs ( 0.04 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.05 CPU)

Testing the speed of creating and dropping tables
Time for create_MANY_tables (10000): 9 wallclock secs ( 0.34 usr 0.06 sys + 0.00 cusr 0.00 csys = 0.40 CPU)
Time to select_group_when_MANY_tables (10000): 1 wallclock secs ( 0.06 usr 0.03 sys + 0.00 cusr 0.00 csys = 0.09 CPU)
Time for drop_table_when_MANY_tables (10000): 1 wallclock secs ( 0.10 usr 0.04 sys + 0.00 cusr 0.00 csys = 0.14 CPU)
Time for create+drop (10000): 9 wallclock secs ( 0.44 usr 0.10 sys + 0.00 cusr 0.00 csys = 0.54 CPU)
Time for create_key+drop (10000): 10 wallclock secs ( 0.35 usr 0.10 sys + 0.00 cusr 0.00 csys = 0.45 CPU)
Total time: 30 wallclock secs ( 1.29 usr 0.33 sys + 0.00 cusr 0.00 csys = 1.62 CPU)

Results on HP DL360 G4

Drive write cache DISABLED

Testing of ALTER TABLE
Time for insert (1000) 0 wallclock secs ( 0.02 usr 0.02 sys + 0.00 cusr 0.00 csys = 0.04 CPU)
Time for alter_table_add (100): 33 wallclock secs ( 0.01 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Time for create_index (8): 4 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for drop_index (8): 3 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for alter_table_drop (91): 33 wallclock secs ( 0.01 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Total time: 75 wallclock secs ( 0.04 usr 0.03 sys + 0.00 cusr 0.00 csys = 0.07 CPU)

Testing the speed of creating and dropping tables
Testing with 10000 tables and 10000 loop count
Time for create_MANY_tables (10000): 1035 wallclock secs ( 1.27 usr 0.25 sys + 0.00 cusr 0.00 csys = 1.52 CPU)
Time to select_group_when_MANY_tables (10000): 83 wallclock secs ( 0.63 usr 0.16 sys + 0.00 cusr 0.00 csys = 0.79 CPU)
Time for drop_table_when_MANY_tables (10000): 493 wallclock secs ( 0.50 usr 0.19 sys + 0.00 cusr 0.00 csys = 0.69 CPU)
Time for create+drop (10000): 958 wallclock secs ( 1.59 usr 0.38 sys + 0.00 cusr 0.00 csys = 1.97 CPU)
(NOTICE: Could not wait for this test to finish, because machine needed to get back in production,)
(thus I assume it to be around 900 seconds just to be on the safe side, probably would be more.)
Total time calculated: around 3400 seconds

Drive write cache ENABLED

Testing of ALTER TABLE
Time for insert (1000) 0 wallclock secs ( 0.02 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Time for alter_table_add (100): 8 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Time for create_index (8): 1 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for drop_index (8): 1 wallclock secs ( 0.00 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.00 CPU)
Time for alter_table_drop (91): 8 wallclock secs ( 0.01 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Total time: 18 wallclock secs ( 0.05 usr 0.02 sys + 0.00 cusr 0.00 csys = 0.06 CPU)

Testing the speed of creating and dropping tables
Time for create_MANY_tables (10000): 104 wallclock secs ( 1.07 usr 0.24 sys + 0.00 cusr 0.00 csys = 1.31 CPU)
Time to select_group_when_MANY_tables (10000): 27 wallclock secs ( 0.48 usr 0.18 sys + 0.00 cusr 0.00 csys = 0.66 CPU)
Time for drop_table_when_MANY_tables (10000): 53 wallclock secs ( 0.32 usr 0.09 sys + 0.00 cusr 0.00 csys = 0.41 CPU)
Time for create+drop (10000): 143 wallclock secs ( 1.31 usr 0.30 sys + 0.00 cusr 0.00 csys = 1.62 CPU)
Time for create_key+drop (10000): 164 wallclock secs ( 1.56 usr 0.36 sys + 0.00 cusr 0.00 csys = 1.92 CPU)
Total time: 491 wallclock secs ( 4.74 usr 1.18 sys + 0.00 cusr 0.00 csys = 5.92 CPU)

Analysis

The test-alter-table results seem fine, slightly over 400% increase in performance. But what bothers me is the test-create difference. I expected the HP DL360 G4 to improve more and execute this test below 100 seconds barier, heck, actually I expected it below 50 seconds. It is true that this machine uses different operating- and filesystem. But 500 seconds still seems too much to me, especially when HP DL380 G5 excells at 30 seconds. If someone know the answer, please drop it in comments.

Conclusion

I believe this article has clearly shown why one must conduct even such synthetic tests before deploying the systems to production environment. Furthermore even before the “real-world benchmarks” are conducted. The phrase “real-world benchmark” signifies a comparative benchmark of certain application on an existing production systems and on the ones that are in testing phase. It often happens that hardware is not upgraded for quite some time, which means that new hardware is few generations younger than the existing one. The new one is far more powerful and one easily misses some not-so-innocent bottleneck if “real-world benchmark” displays certain improvement. Thus, as I believe, newer systems MUST perform better than older ones in every synthetic benchmark (if the systems are comparable, of course), and only then we can start conducting “real-world benchmarks”.

How did I discover this “issue”?

It happened to me back in the 2004 that I deployed such a HP server to collocation facility and only later discovered that it was performing worse than some old test machine lying under my desk. After couple of hours of googling I assumed that the lack of BBWC was our problem. I had to order it and then remove the server from collocation because I also wanted to upgrade all the firmwares, just in case. On top of that, I still had to figure out how to install ‘hpacucli’ on non-RedHat linux. After a long weekend the machine was back in production and never caused a single problem again.

Results
Total execution time is: 562 seconds

# run-all-tests
alter-table: Total time: 8 wallclock secs ( 0.02 usr 0.01 sys + 0.00 cusr 0.00 csys = 0.03 CPU)
ATIS: Total time: 2 wallclock secs ( 1.20 usr 0.09 sys + 0.00 cusr 0.00 csys = 1.29 CPU)
big-tables: Total time: 5 wallclock secs ( 2.45 usr 0.08 sys + 0.00 cusr 0.00 csys = 2.53 CPU)
connect: Total time: 50 wallclock secs (12.74 usr 4.50 sys + 0.00 cusr 0.00 csys = 17.24 CPU)
create: Total time: 31 wallclock secs ( 1.20 usr 0.44 sys + 0.00 cusr 0.00 csys = 1.64 CPU)
insert: Total time: 397 wallclock secs (97.95 usr 13.61 sys + 0.00 cusr 0.00 csys = 111.56 CPU)
select: Total time: 44 wallclock secs ( 8.71 usr 0.88 sys + 0.00 cusr 0.00 csys = 9.59 CPU)
transactions: Test skipped because the database doesn’t support transactions
wisconsin: Total time: 3 wallclock secs ( 0.91 usr 0.23 sys + 0.00 cusr 0.00 csys = 1.14 CPU)
TOTALS 562.00 123.77 19.82 143.59 3425950

System specification can be found here.

ReiserFS vs others
In the age of Linux kernel 2.4.x we used ReiserFS v3 as the filesystem of choice. With the available options of ReiserFS (journal, performance), ext2 (stable but slow) and ext3 (probably stable, but not so speedy as ReiserFS) the choice was obvious. I skipped few years then and this year again tried using ReiserFS with linux 2.6.29.1 but it turned out to be even slower than ext2 was in the old days. Googling around for an answer gave some hints that ReiserFS has an issue with someting called BIG_KERNEL_LOCK on 2.6 kernels. I didn’t really investigate further, but went down the ext3 way.

Comments on test-create
If test-create takes much more time than, say, 30-60 seconds, then you definitely have a problem with filesystem write performance. On HP DL360 and DL380 class of servers this correlates with the presence and activation of BBWC (Battery-Backed Write Cache enabler kit). Without BBWC and hence without write cache enabled, this test took more than 10 minutes to complete. Thus, if you are purchasing some new HP servers, be sure that you also order BBWCs.

Question about test-insert
Looking at the test times, this test-insert result is really standing out. Again, I do not have any other data to compare it to, but somewhere deep down in my memory I seem to remember that the total time for all the tests was around 300 seconds. This obviously means that this test-insert result is the bad guy here. Can someone comment on this result, or paste in the comments his own? Thanks.

Feedback
If you have any questions, recommendations or benchmark results to compare, do not hesitate to leave a comment.

Today I am starting with MySQL, the database of choice for many web developers.

For benchmarking MySQL performance, I primarily use three tools:

1. The MySQL benchmark suite,
2. Super Smack and
3. some custom applications for real world tests.

As it is commonly known, first two items from the list above are not what one might call “real world benchmark suites”. But they are very fine tools for discovering system bottlenecks and obvious configuration errors. Below follow benchmark commands and results with complete (relevant) setup description. Enjoy!

Results for select-key
Queries per second: 166541

cd /usr/share/smacks &&
super-smack select-key.smack 32 100000

Query Barrel Report for client smacker1
connect: max=34ms min=0ms avg= 14ms from 32 clients
Query_type num_queries max_time min_time q_per_s
select_index 6400000 0 0 166541.80

Results for update-key
Queries per second: 9225

cd /usr/share/smacks &&
super-smack update-select.smack 32 10000

Query Barrel Report for client smacker
connect: max=0ms min=0ms avg= 0ms from 32 clients
Query_type num_queries max_time min_time q_per_s
select_index 320000 2 0 9225.27
update_index 320000 2 0 9225.27

Hardware

• HP DL380 g5
• 2x Intel E5420 Xeon (4 cores @ 2.5GHz each)
• 8GB ECC RAM
• 2x 147 SAS 10k drives in hardware RAID-1 configuration
• Write cache enabled for Smart Array P400i

Software

• Slackware 12.2
• Ext3 filesystem
• Linux kernel version 2.4.29.1
• Super Smack 1.3, compiled from source
• MySQL version 5.0.77, compiled from source with configure line:
  

  ./configure –prefix=/usr/local/$PDIR \
  –with-charset=utf8 –with-collation=utf8_general_ci \
  –with-unix-socket-path=/var/mysql/run/mysql.sock \
  –with-mysqld-user=mysql \
  –with-openssl=/usr/local/openssl-0.9.8k

/etc/my.cnf

[client]
socket = /var/mysql/run/mysql.sock

[mysqld]
user = mysql
basedir = /usr/local/mysql
pid-file = /var/mysql/run/mysqld.pid
socket = /var/mysql/run/mysql.sock
datadir = /var/mysql/data
log-error = /var/mysql/log/mysql_error.log
log-slow-queries = /var/mysql/log/mysql_slow_query.log

ssl
ssl-cert = /etc/ssl/certs/_default.cert
ssl-key = /etc/ssl/certs/_default.key

key_buffer = 256M
max_allowed_packet = 32M
table_cache = 256
sort_buffer_size = 2M
read_buffer_size = 4M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
net_buffer_length = 2K
thread_stack = 128K
thread_cache_size = 16K
thread_concurrency = 8
query_cache_size = 32M
max_join_size = 4294967295

innodb_data_home_dir = /var/mysql/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/mysql/data
innodb_log_arch_dir = /var/mysql/data
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 32M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

And also the results of sql-bench suite are here.

Feedback
If you have any questions, recommendations or benchmark results to compare, do not hesitate to leave a comment.