Apache :: ASP

  INTRO
  INSTALL
  CONFIG
  SYNTAX
  EVENTS
  OBJECTS
  SSI
  CGI
  PERLSCRIPT
  COOKIES
  FAQ
- TUNING
  CREDITS
  SUPPORT
  SITES USING
  TODO
  CHANGES

  EXAMPLES

Powered by ModPerl & Apache
Powered by Apache::ASP
TUNING

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
5 hits/second to 25+ hits/second just with the right configuration.
Documented below are some simple things you can do to make the most of your site.
For more tips & tricks on tuning Apache and mod_perl, please see the tuning documents at:
	Stas Bekman's mod_perl guide
	http://perl.apache.org/guide/

	Vivek Khera's mod_perl performance tuning
	http://perl.apache.org/tuning/ 

$Application & $Session State No .htaccess or StatINC
High MaxRequests Turn off Debugging
Precompile Scripts RAM Sparing

$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 cached 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.

High MaxRequests

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 100 - 1000 is probably pretty good.
	
	

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 my PII300, 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 child httpd 
servers.
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 arg. 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 want set that affect compilation. These options include Debug, Global, GlobalPackage, DynamicIncludes, StatINC, and StatINCMatch. 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:
 <Perl>
 Apache::ASP->Loader(
	'c:/proj/site', "(asp|htm)\$",
	Global => '/proj/perllib',
	Debug => 1, # see 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,
	);
 </Perl>
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.

Turn off Debugging

Turn debugging off by setting Debug to 0.  Having the debug config option
on slows things down immensely.
	
	

RAM Sparing

If you have a lot 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 per cached
script.  These numbers are very rough.  If you use includes, you
can instead try setting DynamicIncludes to 1, which will share compiled
code for includes between scripts.
	

Copyright © 1998-2000, Joshua Chamas, Chamas Enterprises Inc.