With mod_perl, the Apache server would run its own built-in Perl interpreter which would be re-used between requests, so that the overhead of having to load the Perl interpreter for every request goes away.
I tested it on my dev server first, and got it all set up and then realized it doesn't work with mod_suexec. With mod_suexec, you can have multiple users on the web server who each have their own websites, and their Perl/CGI scripts will execute in the name of the user instead of as the global Apache user. So then, it makes permission handling easier: the Perl script can read and write files owned by the same user who owns the entire website. But, with mod_perl, the Apache user executes the Perl scripts and this causes problems.
So I found an alternative: FastCGI. It's black magic to me, but it works similarly to mod_perl (reusing the same Perl process for multiple requests), but it does work with mod_suexec. So, I've gotten Kirsle.net and Siikir.com to both use FastCGI now, and, well, both sites run a lot faster. :)
Every request still creates its own unique instance of the Siikir CMS object, but I did tweak my JsonDB plugin a bit for performance too: while every request has its own CMS object, the JsonDB plugin is always a singleton object--it is only initialized once, and then it is shared between every request. Also, it caches the DB documents when it reads them and keeps the cache in memory until the document changes on disk. So this helps tremendously with the file I/O problem on my server. Running the search page on Siikir.com gives results in less than 3 seconds, whereas before it would easily take 10 to 15 seconds.
I'm still keeping a lookout for new bugs that may emerge, though. I have to test and make sure the JSON document caching is working properly, for example. But for now everything seems to be working out pretty well. :)
There are 2 comments on this page. Add yours.
I've switched lots of things from mod_perl to FastCGI lately because it puts the fancy request handling "at an arm's length from" Apache itself.
"Over here, we've got Apache. Very lightweight, very fast, very predictable, small, and so on ... and it stays that way."
"Over there, we've got the FastCGI workers. Bigger, but having become big they sort of stabilize and stay that way. They, too, are predictable, and very different from Apache."
And it ... just works. Instead of one process that transforms itself into a completely different beast with every request that comes in, they share the work and don't change much. To me it's a lot more satisfactory, 'cuz it's so much more predictable.
You should give PSGI/Plack a whirl... it's incredibly fast. (search Perl Plack, and perl plack advent calendar)
0.0084s
.