MySQL and Perl for the Web: Chapter 3 Section 3 (6/6) | WebReference

MySQL and Perl for the Web: Chapter 3 Section 3 (6/6)

To page 1To page 2To page 3To page 4To page 5current page

Improving Performance with mod_perl

Persistent Database Connections

Normally, scripts that use MySQL open a connection to the MySQL server, access the database, and close the connection. Such connections are non-persistent. You can use persistent database connections instead if you want to share connections among database scripts and minimize connection setup overhead. However, you don't actually make any changes to your scripts to do this. Instead, preload the Apache::DBImodule from your mod_perl startup file:

use Apache::DBI ();

Alternatively, use a PerlModule directive in httpd.conf:

PerlModule Apache::DBI

(In either case, if you preload both Apache::DBI and DBI, you should load Apache::DBI first.) After you restart Apache to make the change take effect, each child httpd process will manage a pool of open connections to the MySQL server. This happens transparently to your scripts. DBI's disconnect() method is overridden to become a no-op, and the connect() method is overridden with one that checks whether the database you're connecting to is already open. If so, the connection is reused. For more information, run perldoc Apache::DBI from the command line.

Running Scripts with Special Privileges

You can invoke a standalone Perl script under Apache's suEXEC mechanism to run them under a particular user ID if the script needs higher security or greater privileges. This isn't possible with mod_perl scripts because they run within Apache, and Apache can't change its own user ID (unless you run it as root, which is a huge security risk). A workaround for this in some cases is to run a helper application using suEXEC for that part of your script's task that requires special privileges. Or, if your script doesn't actually require mod_perl, put it in the cgi-bin directory and launch it with suEXEC as a standalone script.

You should now be able to install mod_perl if you want to. And by bearing in mind the discussion just presented concerning mod_perl-related issues to watch out for, you should be able to write scripts that run properly whether or not they run under mod_perl. Of course, none of the programs shown in this chapter really do much of anything; they are intended only to illustrate various aspects of mod_perl's behavior. In the next chapter we'll discuss the design of form-based scripts, an extremely common type of Web application that enables you to accomplish real work.

To page 1To page 2To page 3To page 4To page 5current page

Created: July 13, 2001
Revised: July 13, 2001