In the previous three articles, I introduced my templating system of choice, the Template Toolkit (TT). Since those articles were intended as overviews, I didn’t have much space to go into meaty examples. So, in this article, I’ll look at how I’m using TT every day to help me manage the Stonehenge Consulting web site (http://www.stonehenge.com).
In the previous three articles, I introduced my templating system of choice, the Template Toolkit (TT). Since those articles were intended as overviews, I didn’t have much space to go into meaty examples. So, in this article, I’ll look at how I’m using TT every day to help me manage the Stonehenge Consulting web site (http://www.stonehenge.com).
In the July 2002 edition of this column (available online at http://www.linux-mag.com/2002-07/perl_01.html), I described in detail how I had placed http://www.stonehenge.com under CVS management and how I had chosen to use TT to manage the slight variations required for the files between development versions and production versions. But I glossed over (for lack of room) how I use TT to manage the variations between the front-end, caching-reverse-proxy server and the back-end, heavy Apache mod_perl server, including how to make it easy to have many virtual servers with similar configurations. Let’s look at that now.
A mod_perl-enabled application server generally caches many Perl subroutines and data structures in memory, trading that memory for the delay of reloading such structures from disk or recomputing them time and again. In my case, a typical mod_perl process is about 20 to 30 megabytes of memory. In the “old days,” I let these fat 20 MB processes take care of every request from a browser, including requests for images or static HTML files that really didn’t need mod_perl involved. Besides just wasting resources, this gets particularly nasty when large images are being downloaded…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
