Skip to content

My ass is on fire! Spank my ass

15th August 2008

This has been a rather random few days.

  • I bought a steam-boat (not really; but close enough.)
  • I fell in love with mod_perl

For those of you that don't know it mod_perl is an Apache module which embeds perl into your webserver.

You can use this to write extensions, handlers, and all kinds of fun things in pure perl.

Me? I just changed the beefy CGI script that I use to power a couple of my sites from being plain-CGI to being mod_perl-CGI - that means:

  • The same perl engine & copy of my script stays in memory.
  • I don't need the fork()/exec() overhead for each incoming rquest.

The downside is that I have to "/etc/init.d/apache2 reload" if I change my script, or any of my custom modules it uses. (I suspect this is something I can fix; I just don't know how yet :)

All that was possible, with zero changes to my applications as I use the CGI::Application framework - lucky? or planned? I'll let you decide ...

In terms of speedup I can now process about 100 requests a second, compared to 10. As reported by the Apache-benchmark tool. Cool.

ObFilm: The Mummy: Tomb of the Dragon Emperor

Tags: cgi::application, mod_perl, perl, perl, steam. | 4 comments.

Comments On This Entry

  1. [gravitar] Clifford W. Hansen Submitted at 06:51:48 on 15 August 2008
    I know this will probibly add some overhead, but a friend of mine once put his code in mysql, and then just called it from there. probibly using an eval or something, but he was able to change the code in the mysql table and wouldn't need to restart anything... It was an irc bot... iirc... hth...
  2. [gravitar] Simon Proctor Submitted at 09:55:05 on 15 August 2008
    What you want (on a dev box anyway) is Apache2::Reload that watches your modules and reloads them when they change.
    Bit of overhead but boy does it make things easier.
    I do like mod_perl, I got very into it at my last job, we don't use it as strongly here. Yet.
  3. [gravitar] niq Submitted at 10:19:46 on 15 August 2008
    While mod_perl can improve on perl CGI, so too can other CGI architectures. And to see a x10 improvement hints that you were doing something wrong before. More to the point, if the application is compatible with cacheing at any level, then mod_cache could yield much bigger improvements.
  4. [author] Steve Kemp Submitted at 10:27:08 on 15 August 2008

    Clifford: Storing code to be executed in a database just fills me with fear! Certainly stored procedures may be useful, but anything that stores Perl in a database then fetches it and eval's it seems .. misguided.

    Simon: Thanks for the link. I've been experimenting and it seems to work well for me.

    niq: I'm already using a lot of caching behind the scenes via memcached, but the application as a whole could probably benefit from a reverse-proxy or similar cache at the front.

    As to the speed improvement, on the live site the system doesn't gain so much (and the numbers are off) but that 10x improvement is repeatedly visible upon my test installation which is running on my home desktop machine. There is a lot of code in modules which is used - so I'd almost expect that level of increase if my modules don't have to be searched. Just benchmarking the "require XX:XXX:" from a cold cache shows a significant time is spent loading the code before it is parsed. Whilst it will get cached afterward it is a shock to see the load times drop so much.