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

[previous]

Improving Performance with mod_perl

Should You Use mod_perl?

Now, having made an effort to convince you that mod_perl is a good thing, allow me to point out that you do not have to use it if you don't want to. Indeed, if you run a low-traffic site, performance may be adequate as is, response time for clients may be perfectly satisfactory, and you may never experience any compelling reason to use mod_perl. If you don't want to deal with mod_perl now, just skip ahead to the next chapter. If your site's activity increases, however, you may find performance becomes an issue about which to be concerned. In that case, you can always return to this chapter and reconfigure Apache for mod_perl when you need it.

If you decide to use mod_perl and do find that it's useful (as I expect you will), there are other Apache modules you may want to consider. Perl isn't the only language that can be embedded into Apache as a module; languages such as PHP, Python, Ruby, and Java also can be used in module form for writing Web scripts, with advantages similar to those offered by mod_perl.

If You Are Not Using mod_perl

You should know one thing about this chapter even if you decide to skip it for now: Most of the rest of this book assumes you'll run your scripts under mod_perl. You can recognize such scripts, because they'll be located in the cgi-perl directory, not in cgi-bin. To use any such script in standalone fashion (assuming it doesn't require mod_perl, of course), just put it in your cgi-bin directory and adjust the URL accordingly.

Other Uses for mod_perl

As described thus far, mod_perl is a means for improving performance of Perl scripts on a Web site, and in fact, that's the main reason we use it in this book. mod_perl actually is more than that, however, and the performance boost can be viewed as something of a side effect of its primary purpose.

Apache is written in C and provides a C application programming interface (API). Developers can extend Apache's capabilities by writing modules in C that communicate through that API. But not everybody wants to write C code. This is where mod_perl comes in. Its principal function is to provide an alternative to writing in C by mapping the Apache API onto a Perl API so that you can extend Apache by writing Perl programs. That's why mod_perl embeds the Perl interpreter into Apache--it provides a bridge between the Apache C API and programs written in Perl. The primary effect of this is to make Apache internals available through the Perl language. The secondary side effect (the one we're actually more interested in here) is that because Perl is available immediately and has already been started up, Perl scripts execute significantly faster.

Perl programs that exploit the Perl API can do some clever things. For example, packages such as Embperl, ePerl, and Mason provide you with the ability to write HTML pages that contain embedded Perl code. They use the Perl API to access Apache's page-processing mechanisms, which allows them to look for bits of embedded code, run the Perl interpreter to evaluate the code, and use the results in producing the page. A related module, AxKit, uses mod_perl to process XML pages. mod_perl allows AxKit to combine the power of the Apache API with Perl's XML support to transform XML pages containing embedded Perl into a variety of formats. From the same XML source, for example, you can produce an HTML page for browser display, a printer-friendly version for hard copy, or a minimal-text version for handheld wireless devices.

Alternatives to mod_perl

mod_perl isn't the only mechanism available for speeding up Perl script execution. Others, such as FastCGI and VelociGen, can be used instead of mod_perl or in tandem with it. You can configure Apache to use mod_perl for some scripts and FastCGI or VelociGen for others. For more information, visit www.fastcgi.com and www.velocigen.com.

[previous]