FastCGI

Noah Petherbridge
kirsle
Posted by Noah Petherbridge on Friday, April 29 2011 @ 04:34:26 PM
I decided I'd take some time today to investigate setting up mod_perl to speed up Siikir.com and Kirsle.net, because some of the page load times on both sites were just unacceptable. They both run well on my local dev server (using all the same data as the production server), but I suspect some combination of a slower CPU or slow file I/O time on my production server is the culprit.

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. :)

Categories:

[ Blog ]

Comments

There are 2 comments on this page.

guest
guest
Posted on Sunday, May 01 2011 @ 12:10:55 PM by Mike R.

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.

guest
guest
Posted on Tuesday, September 27 2011 @ 11:45:55 AM by Logicus.

You should give PSGI/Plack a whirl... it's incredibly fast. (search Perl Plack, and perl plack advent calendar)

Add a Comment

Your name:
Your Email:
Message:
Comments can be formatted with Markdown, and you can use
emoticons in your comment.

If you can see this, don't touch the following fields.



Kirsle
Channels
Creativity
Software
Web Tools
Subdomains
Miscellany
Links


Fan Club