wrapper.javaio.buffer_size プロパティ |
||||||||
このプロパティには、JVMとWrapperプロセス間のパイプに利用されるバッファサイズを設定します。 JVMがコンソール出力を書き出す時、パイプが満杯になっていると、書き出そうとするスレッドがブロック(一時停止)します。 これにより、大量の出力を持つアプリケーションのパフォーマンス低下につながります。 Wrapperバージョン3.5.21より以前の全てのバージョンは、 システムのデフォルトバッファサイズ4KBを利用していました。 ほとんどのアプリケーションでは問題ありませんが、長いラインや大量のコンソール出力を持つアプリケーションでは、 ブロッキングにより引き起こされるパフォーマンス低下につながることでしょう。 Wrapperバージョン3.5.21からは、 デフォルトバッファサイズを「65536 (64KB)」に設定しています。 このバッファサイズは、1024 (1KB)から10485760 (10MB)までの値を設定することができます。 「0 (ゼロ)」に設定すると、システムデフォルトサイズを利用します。 デフォルト値は、ほとんどのアプリケーションで動作し、不要なときに多くのメモリを無駄に使わないような基準で選択されています。
コンソールログ出力をレンダリングするシステムでは多くのオーバーヘッドがありますのでご注意ください。
特にWindowsでは当てはまります。
ご利用のアプリケーションが大量のコンソール出力を記録するパフォーマンス問題が上がった場合、
[wrapper.
パフォーマンスを向上させる他の手法は、専用スレッドを使うか確認することで
バッファリングされたコンソール出力を処理する、インターバル(一定間隔)を上げることです。
さらに詳細は、[wrapper. 警告Java出力の全ては、Wrapperプロセスへの自身の「stdout/stderr」(データ標準出力/標準エラー出力)パイプへ送信されます。 もしWrapperがファイルやコンソール書き込みが遅い場合、Javaからの出力を読み込む能力も低下するでしょう。 もしWrapperが全てを読み込んでないために、パイプが満杯になった場合、 Java側のパイプが、その出力を書き込みの試行をブロック(一時停止)するでしょう。 これは、アプリケーションのパフォーマンに大きな影響を与えることになりますので、念頭に置いておくことが大切です。 この問題は、スタンドアローンのJavaプロセスを含み、どのアプリケーションでも起きるでしょう。
この問題を緩和する手法として、
[wrapper. 注意パイプバッファサイズを設定する機能は、現在のところ、Windows上だけです。 UNIXプラットフォームでは、別にパイプサイズを取り扱います。 「ulimit」を利用する設定で可能です。 |
参照: コンソール |
|