アカウント名:
パスワード:
昨今のネットワークの性能からすると、HTTPやPOP3はとても性能が悪いです。
メール容量にしたら、たった2MBほどなんでftpで/var/mail/${USER} を持ってきたら(帯域次第ではあるが)一瞬で転送が終るのだが、POP3を通すと、1. メールを取得, 2. メールのフラッシュ, 3. ローカルの処理待ちを届いたメールの数だけ繰り返す、なおかつ、その度にprocmailをforkするんで遅くて仕方がないです。
ネットワークの遅延を100ms, サーバのレスポンスを50ms, procmailのforkと処理の時間を100msとすると、1つのメールあたり250msかかることになり、2000通メールがたまっていると、どれだけ帯域が広
POP3 の欠陥じゃなく、POP3 を利用して procmail でローカルにデータを持ってくる場合の実装上の欠陥じゃないんですか? それ。 そこらの POP3 に対応した MUA で同じ POP3 サーバーからメールを拾ってきた場合にも同様の時間がかかってますか?
はい。
挙げた例は、fetchmail+procmail+POP3を使っていて、10年くらい前に海外の小国に旅行した際の話です。ネットワークが遅いということもあり、3時間くらい端末の前にずっと座ってました。
/var/mail/${USER} を移動してftpで取ってきて一見落着しました。
あとは、5年くらい前にfetchmail+procmail+POP3で、地方都市のPOP3サーバに対してメールを取りにいったときも(メールの数が多いので)やはりそんな感じでした。3時間というわけではないですが、取得毎に数分くらいは待ってしました。
最近は、(個人では)東京住まいで東京にあるデータセンタにメールを取りにいくのでRTTは低い
サーバー側の実装の話とか、ファイルシステムとかの話もありまして……。 Solaris のような sync mount 大前提のシステムでそのまま Maildir を利用し、大量に新着メールをため込んでいる場合 Maildir/new → Maildir/cur (だったかな?) の移動のために長時間待たされる場合があります。こういうパターンでは、プロトコルどうこうという話にはなりません。
# テストで 4 万通流し込もうとして、うっかり 40 万通流し込んだら 4、5 時間 MUA が応答しませんでした……。
メールの場合はバックエンドがどのようになっているかは不定です。必ずしも各ユーザーのメールがファイルに落ちているとは限りません。 また、IMAP では共有フォルダも参照できます。これを利用する場合、それこそ 1 ファイルに確定できませんし、ローカルにコピーするのは不適切ですね。
また、IMAP では要求と応答は非同期で行うことが可能です。HTTP のパイプライニングと同様に、応答が戻ってくる前に要求を出せます。
それらとは別にサーバーへ ssh 接続ができるのであれば、-C を付けてポートフォワードを行うことで圧縮をかける事も可能ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:3, 興味深い)
昨今のネットワークの性能からすると、HTTPやPOP3はとても性能が悪いです。
メール容量にしたら、たった2MBほどなんでftpで/var/mail/${USER} を持ってきたら
(帯域次第ではあるが)一瞬で転送が終るのだが、POP3を通すと、
1. メールを取得, 2. メールのフラッシュ, 3. ローカルの処理待ち
を届いたメールの数だけ繰り返す、なおかつ、その度にprocmailをforkするんで
遅くて仕方がないです。
ネットワークの遅延を100ms, サーバのレスポンスを50ms, procmailのforkと処理の
時間を100msとすると、1つのメールあたり250msかかることになり、2000通メールが
たまっていると、どれだけ帯域が広
Re: (スコア:1)
POP3 の欠陥じゃなく、POP3 を利用して procmail でローカルにデータを持ってくる場合の実装上の欠陥じゃないんですか? それ。
そこらの POP3 に対応した MUA で同じ POP3 サーバーからメールを拾ってきた場合にも同様の時間がかかってますか?
Re: (スコア:2)
はい。
挙げた例は、fetchmail+procmail+POP3を使っていて、10年くらい前に
海外の小国に旅行した際の話です。ネットワークが遅いということもあり、
3時間くらい端末の前にずっと座ってました。
/var/mail/${USER} を移動してftpで取ってきて一見落着しました。
あとは、5年くらい前にfetchmail+procmail+POP3で、地方都市の
POP3サーバに対してメールを取りにいったときも(メールの数が
多いので)やはりそんな感じでした。3時間というわけではないですが、
取得毎に数分くらいは待ってしました。
最近は、(個人では)東京住まいで東京にあるデータセンタにメールを取り
にいくのでRTTは低い
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
サーバー側の実装の話とか、ファイルシステムとかの話もありまして……。
Solaris のような sync mount 大前提のシステムでそのまま Maildir を利用し、大量に新着メールをため込んでいる場合 Maildir/new → Maildir/cur (だったかな?) の移動のために長時間待たされる場合があります。こういうパターンでは、プロトコルどうこうという話にはなりません。
# テストで 4 万通流し込もうとして、うっかり 40 万通流し込んだら 4、5 時間 MUA が応答しませんでした……。
メールの場合はバックエンドがどのようになっているかは不定です。必ずしも各ユーザーのメールがファイルに落ちているとは限りません。
また、IMAP では共有フォルダも参照できます。これを利用する場合、それこそ 1 ファイルに確定できませんし、ローカルにコピーするのは不適切ですね。
また、IMAP では要求と応答は非同期で行うことが可能です。HTTP のパイプライニングと同様に、応答が戻ってくる前に要求を出せます。
それらとは別にサーバーへ ssh 接続ができるのであれば、-C を付けてポートフォワードを行うことで圧縮をかける事も可能ですね。