説明 : Description

This chapter explains what should or should not be done in order to keep the performance high

このチャプタはパフォーマンスを高く保つために何をおこなうべきか何をおこなうべきではないかを説明します

メモリリーク : Memory Leakage

via: https://perl.apache.org/docs/1.0/guide/performance.html#Memory_leakage

Scripts under mod_perl can very easily leak memory! Global variables stay around indefinitely, lexically scoped variables (declared with my ()) are destroyed when they go out of scope, provided there are no references to them from outside that scope.

mod_perl のもとでスクリプトはとても簡単にメモリをリークします ! グローバル変数はいつまでも存在し続け, レキシカルスコープ化された変数 (my () で宣言される) はスコープの外側からそれへの参照がないという条件で, スコープ外にいくと破棄されます。

Perl doesn't return the memory it acquired from the kernel. It does reuse it though!

Perl はカーネルから獲得したメモリをリターンしません。けれども再利用はします !

適切なメモリプールの使用法 : Proper Memory Pools Usage

Several mod_perl 2.0 APIs are using Apache memory pools for memory management. Mainly because the underlying C API requires that. So every time Apache needs to allocate memory it allocates it using the pool object that is passed as an argument. Apache doesn't frees allocated memory, this happens automatically when a pool ends its life.

いくつかの mod_perl 2.0 API は Apache メモリプールをメモリマネージメントのために使います。主には下層の C API がそれを必要とするからです。ですから Apache がメモリの割り当てを必要とするたびに引数として渡されるプールオブジェクトを使って割り当てします。Apache は割り当てられたメモリを解放しません, これはプールがそのライフを終える時に自動的に発生します。

Different pools have different life lengths. Request pools ($r->pool) are destroyed at the end of each request. Connection pools ($c->pool) are destroyed when the connection is closed. Server pools $s->pool) and the global pools (accessible in the server startup phases, like PerlOpenLogsHandler handlers) are destroyed only when the server exits.

異なるプールは異なるライフの長さをもっています。リクエストのプール ($r->pool) は各リクエストの終わりで破棄されます。コネクションのプール ($c->pool) はそのコネクションがクローズされたときに破棄されます。サーバのプール ($s->pool) とグローバルのプール (PerlOpenLogHandler ハンドラのようにサーバのスタートアップフェーズでアクセスできる) はサーバが終了したときにのみ破棄されます。

Therefore always use the pool of the shortest possible life if you can. Never use server pools during request, when you can use a request pool. For example inside an HTTP handler, don't call:

したがってあなたができるなら可能な限り短いライフのプールを常に使ってください。あなたがリクエストプールを使えるときに, リクエストの間でサーバプールを使わないでください。例えば HTTP ハンドラの内側で, これをコールしないように:

my $dir = Apache2::ServerUtil::server_root_relative($s->process->pool, 'conf');

when you should call:

このときあなたはこれをコールしたほうが良いです:

my $dir = Apache2::ServerUtil::server_root_relative($r->pool, 'conf');

Of course on special occasions, you may want to have something allocated off the server pool if you want the allocated memory to survive through several subsequent requests or connections. But this is normally doesn't apply to the core mod_perl 2.0, but rather for 3rd party extensions.

もちろん特別なときに, 割り当てられたメモリをいくつかの続きのリクエストやコネクションを通じてサバイブさせるためにあなたはサーバプールから何かを割り当てたいかもしれません。しかしこれは普通コアの mod_perl 2.0 ではなく, むしろ 3rd パーティ拡張で適用するものです。

メンテナ : 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

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


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

目次 - Perl Index