Apache :: ASP
< % Web Applications with Apache & mod_perl % >
はじめに
インストール
設定
構文
イベント
オブジェクト
SSI
セッション
XML/XSLT
CGI
PERLスクリプト
FAQ
% チューニング
謝辞
サポート
使用サイト
リソース
計画
履歴
ライセンス

実例

ASP 工作室
日本語訳について

Powered by Apache::ASP
Powered by ModPerl and Apache
Powered by Perl
Links Checked by NodeWorks
SourceForge.jp
チューニング


小さなチューニングをするにもかなりの時間がかかる事もあります。
ちょっとしたチューニングが、何とかやって行けるサイトと快調に(鋭い音を立
てて)機能するサイトを分ける事もあります。Apache::ASPなら、下手に調整された
毎秒10ヒットをこなすサイトに正しい調整をするだけで、毎秒50ヒット以上処理する
サイトに簡単に変える事ができます。
あなたのサイトを最大限に活用するためにできる事を以下に示 します。

オンラインで手に入る資料 スクリプトは前もってコンパイルする
チューニングとベンチマーキング .htaccessやStatINCは使用しない
$Applicationと$Session State デバッギングはオフにする
MaxClientsの値は低く設定する RAMの節約
MaxRequestsPerChildの値は高めに設定する リソースの限界
モジュールは前もってコンパイルする  

オンラインで閲覧できる資料


アパッチやmod_perlのチューニングのコツについてもっと知りたい場合は以下のチューニングについてのドキュメントを読んでください:
  Stas Bekman's mod_perl guide

  Vivek Khera's mod_perl performance tuning
1999年に書かれたこの文書は、Apache::ASPウェブサイトの調整の仕方についての(初期の)見方を提供します: Written in late 1999 this article provides an early look at how to tune your Apache::ASP web site:
  Apache::ASP Site Tuning

チューニングとベンチマーキング

性能を調整する際には、変更を加えるごとにその効果を測定する道具を持つ事が重要です。ab、またはApache Benchはこの機能をうまく提供し、apacheディストリビューションにフリーで含まれています。
性能の調整はきりがないかもしれないので、どこまで到達したら十分かという区切りを設定し、そこで調整をやめるのがいいでしょう。

$Applicationと$Session State

$Applicationや$Sessionオブジェクトが必要でなければ「NoState 1」設定を使いましょう。このような状態オブジェクトはディスク上のファイルと連係しているので、これらを使う事で性能的に不利になります。
もし状態オブジェクト$Applicationと$Sessionが必要であり、 かつファイルをメモリにキャッシュするOSを使用しているのであれば、 StateDirディレクトリをキャッシュ上のファイルシステムに設定してください。 Windows NTの全てのファイルはキャッシュされる可能性があり、あなたが指定 することはできません。Solarisでは/tmpがRAMディスクであり、ここは StateDirに設定するのに良い場所です。キャッシュされるファイルシステムが 使用される場合には、状態ファイルを利用することにより性能が下がります。 Linuxはファイルシステムを上手にキャッシュする傾向があるので、システム 管理が楽になるようにStateDirを決めましょう。
mod_perlリクエストがシリアライズされる Win32システムでは、より速く$Sessionリクエストを行う目的で SessionSerializeを自由に使えます。global.asaのScript_Onstart内で $Application->Lock()を呼ぶことで、同様な性能上の利点が得られるでしょ う。

MaxClientsは低く

それだけの(MaxClientsで指定した)数のhttpdサーバが動作する
場合に(忙しいサイトではあり得るでしょう)、過大なRAMの使用によりシステ
ムがディスクへのスワッピングをし始めない程度にMaxClientsは低く設定しま
しょう。 典型的な設定は、1ギガのRAMがあっても(!)100以下です。より多く
のクライアント接続を処理する場合はデュアルサーバ、mod_proxyフロントエ
ンドの利用を考えましょう。

	
	

MaxRequestsPerChildは多く

一度目にコンパイルされた時ASPスクリプトがキャッシュされる
可能性を高めるために、子スレッドまたはプロセスあたりの最大リクエスト数
を(httpd.conf)で高く設定しましょう。これによりUNIXシステムでプロセスを
フォークすることにより性能が低下するのも避けられます。50〜500でおそら
く十分多いでしょう。RAMを使用しすぎる危険性があるのでこの値を大きくし
過ぎないようにしましょう。動作時にMaxRequestsPerChildを最適に調節する
ためにApache::SizeLimitやApache::GTopLimitを使うこともできます。


	

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 want set that affect compilation. These options include Debug, Global, GlobalPackage, DynamicIncludes, StatINC, StatINCMatch, 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:
 <Perl> 
 Apache::ASP->Loader(
	'/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,
	);
 </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, 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.
	
	

RAM Sparing

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.  If you use includes, you
can instead try setting DynamicIncludes to 1, which will share compiled
code for includes between scripts by turning an <!--#include file..-->
into a $Response->Include().
	
	

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!
 
Copyright © 1998-2002, Joshua Chamas, Chamas Enterprises Inc.