説明 : Description

This chapter discusses how to choose the right MPM to use (on platforms that have such a choice), and how to get the best performance out of it.

このチャプタは使用する正しい MPM の選択方法 (そのような選択肢をもつプラットフォームで) と, そこからベストなパフォーマンスを得る方法を論じます。

Certain kind of applications may show a better performance when running under one mpm, but not the other. Results also may vary from platform to platform.

特定の種類のアプリケーションはある mpm のもとで実行するとより良いパフォーマンスを示すかもしれませんが, 他ではそうでないかもしれません。結果もまたプラットフォームごとに違うかもしれません。

CPAN module developers have to strive making their modules function correctly regardless the mpm they are being deployed under. However they may choose to indentify what MPM the code is running under and do better decisions better on this information, as long as it doesn't break the functionality for other platforms. For examples if a developer provides thread-unsafe code, the module will work correctly under the prefork mpm, but may malfunction under threaded mpms.

CPAN モジュールの開発者はデプロイされている mpm に関係なくモジュールの機能が正しくなるように努めなければなりません。しかしコードが実行されているのがどの MPM かを特定しこの情報でよりよい決定をよりよく行うことを選択することもできます, それが他のプラットフォームの機能を壊さない限りは。例えば開発者が非スレッドセーフのコードを提供する場合, そのモジュールは prefork (# 事前フォーク) mpm のもとでは正しく機能するでしょうが, threaded (# スレッド化された) mpm のもとでは誤作動するはずです。

メモリ要件 : Memory Requirements

Since the very beginning mod_perl users have enjoyed the tremendous speed boost mod_perl was providing, but there is no free lunch -- mod_perl has quite big memory requirements, since it has to store the compiled code in the memory to avoid the code loading and recompilation overhead for each request.

最初期からの mod_perl ユーザは mod_perl が提供するとんでもないスピードブーストをエンジョイしていましたが, 無料のランチはありません -- mod_perl はとてもビッグなメモリ要件をもっています, それは各リクエストでのコードのローディングと再コンパイルのオーバーヘッドを回避するためにメモリにコンパイル済みのコードを格納するからです。

Prefork MPM でのメモリ要件 : Memory Requirement in Prefork MPM

For those familiar with mod_perl 1.0, mod_perl 2.0 has not much new to offer. We still rely on shared memory, try to preload as many things as possible at the server startup and limit the amount of used memory using specially designed for that purpose tools.

mod_perl 1.0 に親しんでいる人々に, mod_perl 2.0 はそれほど新しいことを提供しません。私たちはまだ共有メモリに頼っていて, サーバのスタートアップでできるだけ多くのものをプレロードすることとその目的のために設計された特別なツールを使ってメモリの量を制限することをを試みています。

The new thing is that the core API has been spread across multiply modules, which can be loaded only when needed (this of course works only when mod_perl is built as DSO). This allows us to save some memory. However the savings are not big, since all these modules are writen in C, making them into the text segments of the memory, which is perfectly shared. The savings are more significant at the startup speed, since the startup time, when DSO modules are loaded, is growing almost quadratically as the number of loaded DSO modules grows (because of symbol relocations).

新しいことはそのコア API が複数のモジュールにわたり分散されたことで, これにより必要とされたときにのみロードされることができます (これはもちろん mod_perl が DSO としてビルドされたときにのみ機能します)。これは私たちにいくつかのメモリの節約をできるようにします。しかしその節約はビッグではありません, これらすべてのモジュールは C で書かれていて, それらが完全に共有される, メモリのテキストセグメントにするからです。スタートアップスピードの節約はより重要です, DSO モジュールがロードされるときの, スタートアップタイムは, ロードされる DSO モジュールの数が増えるとほぼ 2 次関数敵に増えるからです (シンボルのリロケーション (# 再配置) のため)。

Threaded MPM でのメモリ要件 : Memory Requirement in Threaded MPM

The threaded MPM is a totally new beast for mod_perl users. If you run several processes, the same memory sharing techniques apply, but usually you want to run as few processes as possible and to have as many threads as possible. Remember that mod_perl 2.0 allows you to have just a few Perl interpreters in the process which otherwise runs multiple threads. So using more threads doesn't mean using significantly more memory, if the maximum number of available Perl interpreters is limited.

threaded MPM は mod_perl ユーザにとってまったく新しいビーストです。あなたがいくつかのプロセスを実行する場合, 同じメモリを共有するテクニックを適用しますが, 通常あなたはできるだけ少ないプロセスを実行してスレッドをできるだけ多くもちたいでしょう。mod_perl 2.0 はあなたにプロセスで数個の Perl インタプリタだけをもてるようにしてそうでない場合に複数のスレッドを実行するようにすること覚えておいてください。ですから Perl インタプリタの利用可能な最大数が制限されている場合に, より多くのスレッドを使うことは著しく多いメモリを使うことを意味しません。

Even though memory sharing is not applicable inside the same process, mod_perl gets a significant memory saving, because Perl interpreters have a shared opcode tree. Similar to the preforked model, all the code that was loaded at the server startup, before Perl interpreters are cloned, will be shared. But there is a significant difference between the two. In the prefork case, the normal memory sharing applies: if a single byte of the memory page gets unshared, the whole page is unshared, meaning that with time less and less memory is shared. In the threaded mpm case, the opcode tree is shared and this doesn't change as the code runs.

メモリ共有は同じプロセス内では適用できませんが, Perl インタプリタが共有オペコードツリーをもっているので, mod_perl は大幅なメモリの節約をゲットします。prefork モデルと同様に, Perl インタプリターがクローンされる前に, サーバのスタートアップでロードされるすべてのコードは, 共有されます。しかしこの 2 つの間には大きな違いがあります。prefork のケースでは, ノーマルメモリ共有が適用されます: メモリページのシングルバイトが共有解除になると, ページ全体が共有解除になり, それは時間とともにメモリの共有が減少することを意味します。threaded mpm のケースでは, オペコードツリーが共有されてこれはコードの実行時に変更されません。

Moreover, since Perl Interpreter pools are used, and the FIFO model is used, if the pool contains three Perl interpreters, but only one is used at any given time, only that interpreter will be ever used, making the other two interpreters consuming very little memory. So if with prefork MPM, you'd think twice before loading mod_perl if all you need is trans handler, with threaded mpm you can do that without paying the price of the significanly increased memory demands. You can have 256 light Apache threads serving static requests, and let's say three Perl interpreters running quick trans handlers, or even heavy but infrequest dynamic requests, when needed.

さらに, Perl インタプリタプールが使われ, FIFO モデルが使われるので, プールが 3 つの Perl インタプリタを含んでいるが, 与えられた時間でひとつのみが使われる場合, そのインタプリタだけが使われて, 他の 2 つのインタプリタはごくわずかなメモリだけを消費するようにします。ですから prefork MPM の場合では, あなたは mod_perl をロードする前によく考えたほうがよいです, もしあなたが必要なすべてがトランスハンドラの場合, threaded mpm では著しく増加したメモリ需要の代償を払うことなくあなたはそれを行うことができます。あなたは静的リクエストをサーブする 256 の軽量な Apache スレッドをもてますし, 3 つの Perl インタプリタがクイックにトランスハンドラや, 必要に応じて, 重いですが (頻度の低い| infrequest の (#? s/inrequest/inrequent/ : s/infrequest/infRequest/)) 動的なリクエストを実行するということもできます。

It's not clear yet, how one will be able to control the amount of running Perl interepreters, based on the memory consumption, because it's not possible to get the memory usage information per thread. However we are thinking about running a garbage collection thread which will cleanup Perl interpreters and occasionaly kill off the unused ones to free up used memory.

メモリ消費に基づいて, 実行する Perl インタプリタの量をどのようにコントロールできるようにするかは, まだ明らかではありません, それはスレッドごとのメモリ使用量の情報をゲットできないからです。しかし私たちは Perl インタプリタをクリーンアップして使用されたメモリを解放するために使われていないものをたまにキルするガベージコレクションスレッドを実行することを検討しています。

データベースとの連携 : Work with DataBases

Prefork MPM のもとでのデータベース連携 : Work with DataBases under Prefork MPM

Apache::DBI works as with mod_perl 1.0, to share database connections.

データベースコネクションを共有するために, Apache::DBI が mod_perl 1.0 と同様に機能します。

Threaded MPM のもとでのデータベース連携 : Work with DataBases under Threaded MPM

The current Apache::DBI should be usable under threaded mpm, though it doesn't share connections across threads. Each Perl interpreter has its own cache, just like in the prefork mpm.

現在 (# 2014) の Apache::DBI は threaded mpm のもとで使えるはずですが, スレッドを横断するコネクションの共有はできません。各 Perl インタプリタは prefork mpm と同じく, それ独自のキャッシュをもっています。

DBI::Pool is a work in progress, which should bring the sharing of database connections across threads of the same process. Watch the mod_perl and dbi-dev lists for updates on this work. Once DBI::Pool is completed it'll either replace Apache::DBI or will be used by it.

DBI::Pool は進行中の作業で, 同じプロセスのスレッドを横断するデータベースコネクションの共有をもたらすはずです。この作業のアップデートは mod_perl と dbi-dev のリストを見てください。DBI::Pool が完了するとそれは Apache::DBI をリプレイスするかそれによって使われます。

メンテナ : Maintainers

Maintainer is the person(s) you should contact with updates, corrections and patches.

• Stas Bekman [http://stason.org/]

作者 : Authors

• Stas Bekman [http://stason.org/]

Only the major authors are listed above. For contributors see the Changes file.

NEXT

次回は、「 Troubleshooting mod_perl problems 」を「 mod_perl 」公式サイト (https://perl.apache.org/index.html) より確認します。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index