view release on metacpan or  search on metacpan

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

<tr bgcolor=white><td colspan=3><b>Configuration</b></td></tr>

	<tr>
	<td bgcolor=pink>AP.htaccess</td>
	<td bgcolor=pink>yes</td>
	<td bgcolor=pink>no</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>0</td>
	<td bgcolor=#c0c0c0>0</td>
	</tr>

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

	<tr>
	<td bgcolor=#c0c0c0>GlobalPackage</td>
	<td bgcolor=#c0c0c0>My::Bookmarks</td>
	<td bgcolor=#c0c0c0>My::Bookmarks</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>SessionSerialize</td>
	<td bgcolor=#c0c0c0>0</td>
	<td bgcolor=#c0c0c0>0</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>SessionTimeout</td>
	<td bgcolor=#c0c0c0>15</td>
	<td bgcolor=#c0c0c0>15</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>StateDir</td>
	<td bgcolor=#c0c0c0>/tmp/bookmarks</td>
	<td bgcolor=#c0c0c0>/tmp/bookmarks</td>
	</tr>


	<tr bgcolor=white>
	<td><b>Comments</b></td>
	<td><font size=-1></font></td>
	<td><font size=-1>Couldn't believe my eyes when I saw there to be so little difference when not using .htaccess.  My guess is that the Apache people optimized this at some point.</font></td>
	</tr>

<tr bgcolor=white>
<td><b>Legend</b></td>
<td colspan=2>
<font size=-2 face=verdana>
Configuration items
that start with AP are Apache configuration options, the
rest are Apache::ASP.  The 
.htaccess one means that configurations are stored in the .htaccess
if yes, if no in a configuration file.  The configuration changes
between benchmarks are highlighted in <font color=pink><b>pink</b></font>.
</font>
</td></tr>
</table>
<p>
</center>

The MaxRequestsPerChild is commonly overlooked in 
web server setup.  What this does is control the
number of requests that a child httpd server may
serve before exiting, and the parent reforking 
another one.  With mod_perl library loading
and script recompilations, a fork is no small thing,
and avoiding the fork penalty is important.
<p>
We had the MaxRequestsPerChild pretty low before 
at 50 but we up it now to 500 which should be fine
for production.  You don't want to set this too high,
or the mod_perl httpds will often take up too much
memory because of leaks, and shared forked code
becoming unshared as it gets dirtied.



<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>
	+31%
	</tt>
</b></td>
<td bgcolor=yellow><tt>17.3 h/s</tt></td>
<td bgcolor=yellow><tt>22.8 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>no</td>
	<td bgcolor=#c0c0c0>no</td>
	</tr>

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

	<tr>
	<td bgcolor=pink>APMaxRequestsPerChild</td>
	<td bgcolor=pink>50</td>
	<td bgcolor=pink>500</td>
	</tr>

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

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

	<tr>
	<td bgcolor=#c0c0c0>GlobalPackage</td>
	<td bgcolor=#c0c0c0>My::Bookmarks</td>
	<td bgcolor=#c0c0c0>My::Bookmarks</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>SessionSerialize</td>
	<td bgcolor=#c0c0c0>0</td>
	<td bgcolor=#c0c0c0>0</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>SessionTimeout</td>
	<td bgcolor=#c0c0c0>15</td>
	<td bgcolor=#c0c0c0>15</td>
	</tr>

	<tr>
	<td bgcolor=#c0c0c0>StateDir</td>
	<td bgcolor=#c0c0c0>/tmp/bookmarks</td>
	<td bgcolor=#c0c0c0>/tmp/bookmarks</td>
	</tr>


	<tr bgcolor=white>
	<td><b>Comments</b></td>
	<td><font size=-1>Couldn't believe my eyes when I saw there to be so little difference when not using .htaccess.  My guess is that the Apache people optimized this at some point.</font></td>
	<td><font size=-1>This bench only had 684 requests, so there was no parent httpd forking during this time, whereas before there may have been reforking every few seconds during the 30 second bench.</font></td>
	</tr>

<tr bgcolor=white>
<td><b>Legend</b></td>
<td colspan=2>
<font size=-2 face=verdana>
Configuration items
that start with AP are Apache configuration options, the
rest are Apache::ASP.  The 
.htaccess one means that configurations are stored in the .htaccess
if yes, if no in a configuration file.  The configuration changes
between benchmarks are highlighted in <font color=pink><b>pink</b></font>.
</font>
</td></tr>
</table>
<p>
</center>

Back to Apache::ASP, and some finer tuning.  By
default SessionSerialize is 0, and we are going
to turn it on.  What this does is lock $Session
for exclusive use during the course of the script
being run, so that any reads or writes to $Session
don't have to lock it every time.  Because of the i/o
requirements of SDBM_File, each time $Session is read from
or written to, it is freshly tied to the 
database and locked, so to avoid these ties can save much.
<p>
The reason why SessionSerialize is not enabled
by default is that one could easily deny service
to a user with a long running script, such that no
other scripts for that same user $Session could be run,
and this requires some expertise.
Also SessionSerialize is probably not a good thing 
for framed sites, where there is greater concurrency 
for the same $Session.



<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>
	+12%
	</tt>
</b></td>
<td bgcolor=yellow><tt>22.8 h/s</tt></td>
<td bgcolor=yellow><tt>25.74 h/s</tt></td>
</tr>
<tr bgcolor=white><td colspan=3><b>Configuration</b></td></tr>