view release on metacpan or  search on metacpan

site/articles/perlmonth3_tune.html  view on Meta::CPAN

</blockquote>

<h2>Apache::ASP Site Tuning</h2>
by Joshua Chamas <i>&lt;chamas&nbsp;at&nbsp;alumni.stanford.org&gt;</i>
<p>



Last month, we used Apache::ASP to build a simple 
<a href=http://www.apache-asp.org/apps/bookmarks/>MyBookmarks</a>
web application.  Now we are going to tune the 
<a href=http://www.apache-asp.org/>Apache::ASP</a> web application and 
<a href=http://www.apache.org>Apache</a> web server, taking a mild mannered 
web app running at <tt>250,000</tt> pages per day, and boosting it up 4 times 
to a <tt>1,000,000</tt> pages per day powerhouse.
<p>
Are you ready? <font size=+1>Let's Tune!</font>
<p>

<h3>Methodology</h3>
The application was taken as it was built last week,
and incrementally benchmarked, changing one configuration
setting at a time, and showing the performance changes 
below.  The URL tested is the main URL of the application,
<a href=http://www.apache-asp.org/apps/bookmarks/index.asp
  >.../bookmarks/index.asp</a>.
<p>
The application is run on a Solaris x86 box, PII300 512K cache
with 2 4G 7200 RPM SCSI drives in a software RAID 1 configuration.  
The following numbers are not meant to be compared against
other web application environments, or systems, but show 
relative performance improvements when tuning Apache::ASP 
and Apache on this particular system.
<p>
The web server software being tested is apache 1.3.4, with 
the testing client <tt>ab</tt>, or ApacheBench, 
run locally on the server.  Because ApacheBench does not support
cookies, a new Apache::ASP $Session is created in StateDir
for every request, so that the benchmark numbers are worse 
than what you would see in a production setting.  Obviously testing locally
does not take into account many slow client connections
over the internet, which would likely be offset by a reverse
proxy accelerator in production 
(<a href=http://perl.apache.org/guide>see mod_perl guide</a>).
<p>
The <tt>ab</tt> program was run with 5 concurrent clients for 
30 seconds with the following command:
<pre>
  ab -c 5 -t 30 http:// $HOST /bookmarks/index.asp
</pre>

<h3>Tuning</h3>

After running the first bench, and watching the system under
top, it becomes strikingly clear that disk i/o is the bottleneck,
with 50%+ of the time spent waiting for disk.  The reason
is that state management for $Session and $Application uses
SDBM_File, or optionally DB_File, databases on disk to store data, 
and is highly i/o intensive.
<p>
The <i>trick</i> then is to relocate the <tt>StateDir</tt> 
to a fast cached file system.  On Solaris, this happens to 
be /tmp/... by default, but on Linux and WinNT, the file systems seem
to be cached automatically, so you may not need to do anything
except locate <tt>StateDir</tt> to a secure, non-browsable, location.
Using a cached or RAM file system will also spare your disk, which is good 
as it is often the first thing to go on your box.



<center>
<p>
<table border=0 bgcolor=gray>

<tr bgcolor=white>
<td><b>Hits/sec</b></td>
<td align=center><b>Before</b></td>
<td align=center><b>After</b></td>
</tr>

<tr>
<td bgcolor=#bbccff>
	<tt>
	+116%
	</tt>
</b></td>
<td bgcolor=yellow><tt>6.5 h/s</tt></td>
<td bgcolor=yellow><tt>14.1 h/s</tt></td>
</tr>
<tr bgcolor=white><td colspan=3><b>Configuration</b></td></tr>

	<tr>
	<td bgcolor=#c0c0c0>AP.htaccess</td>
	<td bgcolor=#c0c0c0>yes</td>
	<td bgcolor=#c0c0c0>yes</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>APMaxClients</td>
	<td bgcolor=#c0c0c0>5</td>
	<td bgcolor=#c0c0c0>5</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>APMaxRequestsPerChild</td>
	<td bgcolor=#c0c0c0>50</td>
	<td bgcolor=#c0c0c0>50</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>Debug</td>
	<td bgcolor=#c0c0c0>1</td>
	<td bgcolor=#c0c0c0>1</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>Global</td>
	<td bgcolor=#c0c0c0>.</td>
	<td bgcolor=#c0c0c0>.</td>
	</tr>