<% Web Applications with Apache & mod_perl %>


Powered by Apache::ASP
Powered by ModPerl and Apache
Powered by Perl
A little tuning can go a long way, and can make the difference between a web site that gets by, and a site that screams with speed. With Apache::ASP, you can easily take a poorly tuned site running at 10 hits/second to 50+ hits/second just with the right configuration.
Documented below are some simple things you can do to make the most of your site.

Online Resources Precompile Scripts
Tuning & Benchmarking No .htaccess or StatINC
$Application & $Session State Turn off Debugging
Low MaxClients Memory Sparing, NoCache
High MaxRequestsPerChild Resource Limits
Precompile Modules  

Online Resources

For more tips & tricks on tuning Apache and mod_perl, please see the tuning
documents at:
  Stas Bekman's mod_perl guide
Written in late 1999 this article provides an early look at how to tune your Apache::ASP web site. It has since been updated to remain current with Apache::ASP v2.29+
  Apache::ASP Site Tuning

Tuning & Benchmarking

When performance tuning, it is important to have a tool to
measure the impact of your tuning change by change.
The program ab, or Apache Bench, provides this functionality
well, and is freely included in the apache distribution.
Because performance tuning can be a neverending affair, it is a good idea to establish a threshold where performance is "good enough", that once reached, tuning stops.

$Application & $Session State

Use NoState 1 setting if you don't need the $Application or $Session
objects. State objects such as these tie to files on disk and will incur a
performance penalty.
If you need the state objects $Application and $Session, and if running an OS that caches files in memory, set your "StateDir" directory to a cached file system. On WinNT, all files may be cached, and you have no control of this. On Solaris, /tmp is a RAM disk and would be a good place to set the "StateDir" config setting to. When cached file systems are used there is little performance penalty for using state files. Linux tends to do a good job caching its file systems, so pick a StateDir for ease of system administration.
On Win32 systems, where mod_perl requests are serialized, you can freely use SessionSerialize to make your $Session requests faster, and you can achieve similar performance benefits for $Application if you call $Application->Lock() in your global.asa's Script_OnStart.

Low MaxClients

Set your MaxClients low, such that if you have that
many httpd servers running, which will happen on busy site,
your system will not start swapping to disk because of 
excessive RAM usage.  Typical settings are less than 100
even with 1 gig RAM!  To handle more client connections,
look into a dual server, mod_proxy front end.

High MaxRequestsPerChild

Set your max requests per child thread or process (in httpd.conf) high, 
so that ASP scripts have a better chance being cached, which happens after 
they are first compiled.  You will also avoid the process fork penalty on 
UNIX systems.  Somewhere between 50 - 500 is probably pretty good.
You do not want to set this too high though or you will risk having
your web processes use too much RAM.  One may use Apache::SizeLimit
or Apache::GTopLimit to optimally tune MaxRequestsPerChild at runtime.

Precompile Modules

For those modules that your Apache::ASP application uses,
make sure that they are loaded in your sites startup.pl
file, or loaded with PerlModule in your httpd.conf, so 
that your modules are compiled pre-fork in the parent httpd.

Precompile Scripts

Precompile your scripts by using the Apache::ASP->Loader() routine
documented below.  This will at least save the first user hitting 
a script from suffering compile time lag.  On UNIX, precompiling scripts
upon server startup allows this code to be shared with forked child
www servers, so you reduce overall memory usage, and use less CPU 
compiling scripts for each separate www server process.  These 
savings could be significant.  On a PII300 Solaris x86, it takes a couple seconds
to compile 28 scripts upon server startup, with an average of 50K RAM
per compiled script, and this savings is passed on to the ALL child httpd 
servers, so total savings would be 50Kx28x20(MaxClients)=28M!
Apache::ASP->Loader() can be called to precompile scripts and even entire ASP applications at server startup. Note also that in modperl, you can precompile modules with the PerlModule config directive, which is highly recommended.
 Apache::ASP->Loader($path, $pattern, %config)
This routine takes a file or directory as its first argument. If a file, that file will be compiled. If a directory, that directory will be recursed, and all files in it whose file name matches $pattern will be compiled. $pattern defaults to .*, which says that all scripts in a directory will be compiled by default.
The %config args, are the config options that you may want set that affect compilation. These options include: Debug, Global, GlobalPackage, DynamicIncludes, IncludesDir, InodeNames, PodComments, StatINC, StatINCMatch, UseStrict, XMLSubsPerlArgs, XMLSubsMatch, and XMLSubsStrict. If your scripts are later run with different config options, your scripts may have to be recompiled.
Here is an example of use in a *.conf file:
	'/usr/local/proj/site', "(asp|htm)\$", 
	'Global' => '/proj/perllib',
	'Debug' => -3, # see system output when starting apache

	# OPTIONAL configs if you use them in your apache configuration
	# these settings affect how the scripts are compiled and loaded
	'GlobalPackage' => 'SomePackageName',
	'DynamicIncludes' => 1,	
	'StatINC' => 1,		
        'StatINCMatch' => 'My',
        'UseStrict' => 1,
        'XMLSubsMatch' => 'my:\w+',
        'XMLSubsStrict' => 0 || 1,
This config section tells the server to compile all scripts in c:/proj/site that end in asp or htm, and print debugging output so you can see it work. It also sets the Global directory to be /proj/perllib, which needs to be the same as your real config since scripts are cached uniquely by their Global directory. You will probably want to use this on a production server, unless you cannot afford the extra startup time.
To see precompiling in action, set Debug to 1 for the Loader() and for your application in general and watch your error_log for messages indicating scripts being cached.

No .htaccess or StatINC

Don't use .htaccess files or the StatINC setting in a production system
as there are many more files touched per request using these features.  I've
seen performance slow down by half because of using these.  For eliminating
the .htaccess file, move settings into *.conf Apache files.
Instead of StatINC, try using the StatINCMatch config, which will check a small subset of perl libraries for changes. This config is fine for a production environment, and if used well might only incur a 10-20% performance penalty, depending on the number of modules your system loads in all, as each module needs to be checked for changes on a per request basis.

Turn off Debugging

Turn off system debugging by setting Debug to 0-3.  Having the system 
debug config option on slows things down immensely, but can be useful
when troubleshooting your application.  System level debugging is 
settings -3 through -1, where user level debugging is 1 to 3.  User level
debugging is much more light weight depending on how many $Reponse->Debug()
statements you use in your program, and you may want to leave it on.

Memory Sparing, NoCache

If you have a lot (1000's+) of scripts, and limited memory, set NoCache to 1,
so that compiled scripts are not cached in memory.  You lose about
10-15% in speed for small scripts, but save at least 10K RAM per cached
script.  These numbers are very rough and will largely depend on the size
of your scripts and includes.

Resource Limits

Make sure your web processes do not use too many resources
like CPU or RAM with the handy Apache::Resource module.
Such a config might look like:
 PerlModule Apache::Resource
 PerlSetEnv PERL_RLIMIT_CPU  1000
 PerlSetEnv PERL_RLIMIT_DATA 60:60
If ever a web process should begin to take more than 60M ram or use more than 1000 CPU seconds, it will be killed by the OS this way. You only want to use this configuration to protect against runaway processes and web program errors, not for terminating a normally functioning system, so set these limits HIGH!