mod_perl will execute that script at server startup, loading in much of the website. The importiant thing is that this is done before apache forks it's children, so much of the codebase can stay pre-loaded/pre-compiled in shared memory. Copy-on-write is a big win here.

This makes for a slighly slower startup time, but the improvements in memory consumption and initial request performance make for better overall performance.

With mod_perl turned all the way up (no PerlRunOnce, etc.), you'll get better performance at the cost of greater memory usage, though with the improved performance you can usualy tune down the number of servers.

Another configuration with mod_perl/Apache is to put a non-mod_perl apache instance in front of the mod_perl instance and have the non-mod_perl server handle all of the static content requests (like images, pdfs, plain html files, etc.). That keeps the mod_perl servers in reserve to do the dynamic content generation.

If you want to do this, I'd suggest looking into using Apache's RewriteEngine directives. Mandrake used to set up multiple instances of apache this way out of the box.

hth,

Kyle

The route I take for trimmed down webservice is to run two different apache instances. One on the normal port 80 and another on a different port (or different machine). That way I can use the power of apache to scale that back-end server with well known and documented techniques.

First off, are you using mod_perl because that will give you a much better performance increase than trying to optimise the reading of a file.

Even if you are why not just let the OS handle deciding what files to keep in memory? And instead look for other bottlenecks in your code for which you will get a better return on your effort?

If don't like the idea of trusting the OS to decide what files to cache, and you really want to make it faster because this is where the bottleneck is(which I doubt), you could just use a ramdisk/tmpfs and copy the files there before using them. That way you can get the extra performance while still keeping a simple interface in your script (open, read close) with fewer dependances. Although you will probably not get the performance increase that you were expecting because the OS is normally pretty darn good at caching files.

You might also want to look into FastCGI http://www.fastcgi.com/ which allows you to run a cgi as a persistent process external to the webserver, and then the webserver connects to the CGI over TCP or a UDS.

Good idea? Depends on how it becomes a component in your general system. If it's a centralized place for doing stuff vs doing it over and over again, it could be good.

Reinventing the wheel? As someone else posted, it sounds like a webservice. To me, it sounds like a souped up NFS service. *** look up the issues on NFS before continuing! there are locking and timing issues to be concerned about! ***

TCP. I don't *think* there are unix sockets on windows. :)

If the processing of the templates if complicated, there could be some advantage to caching the result. If you want a shared or persistent cache, storing it to disk makes the most sense. The disk cache will make read efficient and it is shared between all processes.