Performance boost for LAMP stack

This weekend I got around to benchmarking conshell.net and my own website using apachebench (ab). For some time I suspected conshell as having sluggish performance and ab showed it was only able to serve three requests per second for the home page.

So I added varnish and APC to the mix, the performance increases 3x. I recommend anyone with a sluggish LAMP server look into these two options.

Here are my #s from ab.

ab -n20 -c2 http://conshell.net/wiki/index.php/Special:Specialpages
http://conshell.net/wiki/index.php/Special:Specialpages
noapc-novarnish  Requests per second:    3.28 [#/sec] (mean)
noacp-varnish    Requests per second:    3.43 [#/sec] (mean)
apc-novarnish    Requests per second:    8.17 [#/sec] (mean)
apc-varnish      Requests per second:    9.94 [#/sec] (mean)


ab -n20 -c2 http://conshell.net/wiki/index.php/Main_Page
http://conshell.net/wiki/index.php/Main_Page
noapc-novarnish  Requests per second:    2.77 [#/sec] (mean)
noapc-varnish    Requests per second:    3.02 [#/sec] (mean)
apc-novarnish    Requests per second:    8.26 [#/sec] (mean)
apc-varnish      Requests per second:    9.65 [#/sec] (mean)

svnspam released @ Google Code

I have uploaded source code for svnspam to Google code for it's first v0.1 release. It's still a bit rough around the edges but a wonderful way to track, visualize and audit code changes in a Subversion repository.

Thanks to BitPusher for sponsoring this work. Feel free to get involved or join the project if you are so inclined.

libmap.conf to the rescue!

Tonight I found myself tripped up by the dreaded "shared object not found" message on my FreeBSD server 'sonar'. See, I upgraded from 6.3-REL to 7.0-REL recently and in doing so, broke probably every port that had been installed prior. In this instance, my nagios plugin(s) were not working.

root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonar
/libexec/ld-elf.so.1: Shared object "libssl.so.4" not found, required by "check_smtp"

Here's the deal, whenever FreeBSD releases a new version they bump the library version numbers as a matter of course. So there may be little to no fundamental difference between libcrypto.so.4 libcrypto.so.5. Or maybe there is. That's why this is risky... but what have I got to lose?

Cut to the chase... if ldd /path/to/binary reveals one or more libraries that aren't found, it can be time for entries in /etc/libmap.conf (instead of the safer/slower choice of rebuilding the port providing said binary).

/usr/local/libexec/nagios/check_smtp:
        libssl.so.4 => not found (0x0)
        libcrypto.so.4 => not found (0x0)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x40746000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x40852000)
        libc.so.6 => not found (0x0)
        libc.so.7 => /lib/libc.so.7 (0x40956000)

By using `locate libssl.so` and variants I was able to see that the libraries were in fact available, only the versions had been incremented. Here are the libmap.conf entries I created.

libssl.so.4     libssl.so.5
libcrypto.so.4  libcrypto.so.5
libc.so.6       libc.so.7

Now my program is fixed.

root@sonar:/tmp>/usr/local/libexec/nagios/check_smtp -H sonar
SMTP OK - 0.072 sec. response time|time=0.071886s;;;0.000000