Preparing for upgrades and testing speed improvements for my homepage / 2015-02-23

As part of a needed upgrade on my homeserver I will also have to deal with Apache 2.4 and the changes needed there. Because some other things will change completely like asterisk I used an old server with comparable packages to do the same upgrades and test the results.

As keen visitors to my page may have noticed I am interested in the performance. This test-setup also gives me room to experiment with some possible new methods. I have to establish a baseline on that server first since it has different hardware.

One thing I decided to try was mod_perl which embeds the perl interpreter into the webserver which can influence reaction times. Playing with the options available in Firefox to see timings made me note a difference in reaction time as measured by the homepage script (at the moment around 120 milliseconds) and as measured as waiting+receiving time by the browser (around 390 milliseconds). Testing this on the test server with mod_perl gives me:

• Without mod_perl: 170 milliseconds in script, 420 milliseconds waiting and receiving.
• With mod_perl first run (nothing cached): 167 milliseconds in script, 405 milliseconds waiting and receiving.
• With mod_perl with scripts cached and persistent database connections set up: 82 milliseconds in script, 207 milliseconds waiting and receiving.

I was aware of mod_perl earlier (years ago) but the stern warnings about having to write scripts differently for mod_perl kept me from trying this for my own homepage. It's possible to have a script already running which just starts a handler for each call (handler mode) or to have a script available which gets cached by the server perl process when first ran and which gets rerun on the next calls (registry mode). Perl scripts in mod_perl 'Registry mode' need to be somewhat aware of the environment: state is kept across calls. Modern scripts with 'use strict' and 'taint mode' should give little problems although taintmode needs to be enabled in the Apache configuration (see below). One thing I noticed was lingering database connections. The best way to solve this was to load Apache::DBI from Apache itself and leave the scripts unchanged, so I created a /etc/apache2/conf-enabled/perl.conf with:

PerlSwitches -T
PerlModule Apache::DBI

Not having the Apache::DBI module available gives a very long wait and a general Apache internal error 400.

On the virtualhost where I use mod_perl the configuration is:

	Options +ExecCGI
	AddHandler perl-script .cgi
	PerlResponseHandler ModPerl::Registry
	PerlOptions +ParseHeaders

See also:

• Getting your feet wet with mod_perl
• Access control in Apache 2.4 which is quite different from 2.2 and before