久しぶりの Memo です？

次の版ですが、IMAP4 及び Webmail のパフォーマンス改善を行います。

まず IMAP4 ですが、クライアントで比較的多く使われるコマンドに FETCH コマンド（メールを指定条件に従って検索を行ってその応答を取得する）があります。

この FETCH コマンドですが、サーバー側では各メールを解析してメールの構造を応答を返すのですが、この処理が結構重いので、ここの改善を行っています。

おおよそですが、従来の解析速度は応答を送信する時間も含めて、
ランダムな 814 メール / 627,272byte で 3.5秒程かかっていた時間が
同条件で、2.2秒程に短縮されています。

もちろん、CPU パワー、ストレージの速度、ネットワークの速度に大きく影響を受け、また対象のメールの構造によっても左右されますが、少なくとも以前よりは改善されています。

ちなみに、この時間の内訳のその９割がストレージの速度とネットワーク速度に依存します（メールの解析自体は、Core i3 2.13MHz で改善前は 0.45ms/mail 改善後は 0.23ms/mail 程度しか掛かっていませんので）

少し余談となりますが、IMAP4 を利用する場合、CPU パワーやネットワーク速度よりもストレージの速度が大きく影響します。
これは IMAP4 の特性上仕方が無いのですが、IMAP4 には「メールの移動」という物は無く「メールのコピー」と「メールの削除」しかありません。

IMAP4 クライアントでメールをフォルダの間で移動するケースは多々ありますが、サーバー側では、eml ファイルを移動しているのでは無く、eml ファイルを新しいフォルダにコピーして、元のフォルダの eml ファイルを削除する。というような動作になります。

従って、IMAP4 を利用してパフォーマンスを出したい場合は、ストレージを高速な物に変更しますと劇的に変化します。（最近は SSD も安くなっていますので）

余談の余談ですが、物理コピーを無くして、メールのコピーが行われたらインデックスのみを更新してという処理にしますと物理コピーが無くなるので劇的に早くなるのですが、この方式はデメリットもありまして、保守性が著しく失われます。

現在の PMail Server2 はバックアップやサーバーからサーバーへの移動はインストールフォルダごとコピーを行えば、それで完了になりますが、そういうことが出来なくなったり、メールボックスの中にメールが溜まりすぎて、ユーザーが受信しきれなくなったから強制的に削除するなどが手動で出来なくなります。
完全に Spool 以下のフォルダを管理者がアクセスできないようにする（手動で操作した場合は、サーバーの動作保証をしない）とすれば可能には可能ですが、保守性と開発コストとパフォーマンス向上を考えると、前者の方が優先順位は高いと考えていますので。

閑話休題

それ以外にも IMAP4 サーバーの内部処理をいくつか見直しておりトータル的にパフォーマンスは上昇しています。

もう１点、これは IMAP4 の副産物ですが、メールの解析処理を向上した為、Webmail 側の処理速度も向上しています。

向上したついで？に、以前から気になっていた Webmail 用のメールキャッシュ処理の見直しも行います。

通常、メールのキャッシュ処理は追加されたメールを順次キャッシュに追加していく為、その状態であれば殆どストレス無しで利用ができているはずですが、IMAP4 にも関連しますが、IMAP4 で大量のメールを移動した後に、そのフォルダに対して Webmail でアクセスをしますと、キャッシュの再生成が始まり、場合によってはブラウザのタイムアウトを引き起こします。（ブラウザのタイムアウト時間は各ブラウザで設定または固定されているので変更ができない場合もあります）

Java Script を使った非同期通信でプログレスバーを表示することも考えましたが（通信はしているのでタイムアウトしません）1,000メール程度であれば、1分程度待つだけですが、これが 10,000メールだと 10分待たないとメールが見れないということになります。
非同期通信で処理が完了したメールからブラウザに順次追加していくことも考えましたが、古いブラウザだと正常に動かないこともある、折衷案として、処理数では無く処理時間で Webmail 側でタイムアウトして、再度アクセスした場合は、その続きから処理を再開する。という仕組みにしました。



タイムアウトすると、こんな感じでメッセージが表示されます。
この状態で返信等の処理全てが可能です。



再度アクセスすると、処理できるメール数が増えています。



もう一度アクセスすると全てのメールの処理が完了しています。

メールは原則として新しいメールから処理されていきますので、全てのメール処理が終わらないと返信ができない。という状況にはなりません。（古いメールを参照したい場合は、そこまで処理を終わらせないとできませんが）

ちなみに Webmail は何かの処理を行った直後にブラウザを終了しても、サーバー側の Webmail は継続して処理を続行しています。

上記のメール約、7,000通は約８分くらい処理に時間がかかるのですが、言い換えてみれば、CGI プロセスが８分間サーバー側で稼動し続けることになります。
ここを１分単位で区切りことによりサーバー側の負荷を分散することにも繋がっています。

元々 PMail Server2 は大規模な運用は想定していないのですが、それなりの規模で運用しているケースもあるようですのでこれらの変更はサーバー側にも優しい仕様になります（笑）

まだ 2.26a のリリース時期については確定しておりませんが、IMAP4 関連のパフォーマンスの見直しとテストが完了した時点でリリースを行いたいと思います。