The Perl interpreter is the brain of the mod_perl server. If you can optimize Perl into doing things faster under mod_perl, you'll make the whole server faster. Generally, optimizing the Perl interpreter means enabling or disabling some build options. Let's look at a few important ones. (Note that you have to build Perl before you build mod_perl-enabled Apache. If you have rebuilt the Perl interpreter, make sure to rebuild mod_perl as well, or the changes won't affect mod_perl.)

You can pass build options to Perl via the Configure script. To specify additional C compiler flags, use the -Accflags=... Configure command-line option (e.g., -Accflags=-DFOO will define the C preprocessor symbol FOO.) You can also pass additional optimizer/debugger flags via -Doptimize=... (e.g., -Doptimize='-O2 -march=pentium').

Don't enable Perl's thread support unless you need it, because some internal data structures are modified and/or extended under ithreads/5005threads—this may make certain things slower and could lead to extra memory usage.

You have a choice of using the native or Perl's own malloc( ) implementation. The default choice depends on your operating system. On some OSes the native implementation might be worse than Perl's. Unless you know which of the two is better on yours, try both and compare the benchmarks.

To build without Perl's malloc( ), you can use the Configure command:

panic% sh Configure -Uusemymalloc

Note that:

-U =  = undefine usemymalloc (=  = use system malloc)
-D =  = define   usemymalloc (=  = use Perl's malloc)

The Linux OS still defaults to system malloc( ), so you might want to configure Perl with -Dusemymalloc. Perl's malloc( ) is not much of an imporovement under Linux (it's about a 5-10% speed improvement according to Scott Thomason, as explained at, but it makes a huge difference under Solaris (when using Sun's C compiler). Be sure also to check the README.* file corresponding to your OS in the Perl source code distribution for specific instructions and caveats.