As I mentioned last month, having persistent Perl code means that some steps of your application can be reused rather than repeated. One very easy optimization is keeping your database handles open between web hits, rather than reopening them on each new hit. The Apache::DBI module (found in the CPAN) does the work for you by altering the way normal DBI connections are processed.
As I mentioned last month, having persistent Perl code means that some steps of your application can be reused rather than repeated. One very easy optimization is keeping your database handles open between web hits, rather than reopening them on each new hit. The Apache::DBI module (found in the CPAN) does the work for you by altering the way normal DBI connections are processed.
If your application is like most, you simply add PerlModule Apache::DBI to the configuration file, and it just magically works. The disconnect() method of DBI is altered so that it doesn’t really disconnect, and the connect() method attempts to reuse an already existing handle opened with the same database parameters (including user and password).
The upside is efficiency. The downside is that every mod_ perl Apache process eventually gets one or more persistent connections to the database server, which may affect a license count or a process limit.
Another nice module is Apache::Template (also in the CPAN). This module turns your page deliveries into a full, embedded templating system using Template Toolkit. The configuration is similar to Apache::Registry (shown last month):
Now each file located within the directory mapped from the /tt2 URL is treated as a template in the Template Toolkit language. The template is compiled into Perl code and executed, and the result is delivered to the web client.
With additional directives, the results…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
