アカウント名:
パスワード:
昨今のネットワークの性能からすると、HTTPやPOP3はとても性能が悪いです。
メール容量にしたら、たった2MBほどなんでftpで/var/mail/${USER} を持ってきたら(帯域次第ではあるが)一瞬で転送が終るのだが、POP3を通すと、1. メールを取得, 2. メールのフラッシュ, 3. ローカルの処理待ちを届いたメールの数だけ繰り返す、なおかつ、その度にprocmailをforkするんで遅くて仕方がないです。
ネットワークの遅延を100ms, サーバのレスポンスを50ms, procmailのforkと処理の時間を100msとすると、1つのメールあたり250msかかることになり、2000通メールがたまっていると、どれだけ帯域が広くても50秒以上の時間がかかることになる。
以上は簡単に計算した結果だが、TCPの初期転送速度は非常に遅いので、メールのサイズが1500バイトに収まらない場合、実際には、もっと遅くなってしまう。例えば、30KBのメールが届いたとすると、サーバの負荷がどれだけ低くても、最短でも5RTT(100ms*5RTT=500ms)がかかってしまうことになる。
1RTT: 15002RTT: 1500+3000=45003RTT: 4500+6000=105004RTT: 10,500+12,000=22,5005RTT: 22,500+24,000>30,000
同時にメールを取得して同時にメールをフラッシュできるようなプロトコルがあればPOPメールのフラッシュを待たなくてもよいと思うのだけど、最近のメール転送プロトコルには、このようなPOP3の欠点を隠せるような設計が盛り込まれているのでしょうか?
2000通メールがたまっていると、どれだけ帯域が広くても50秒以上の時間がかかる
なので、POP を使うならメールを溜め込まないようにしましょう。procmail 使ってなくても、概略同上。
POP3 の欠陥じゃなく、POP3 を利用して procmail でローカルにデータを持ってくる場合の実装上の欠陥じゃないんですか? それ。 そこらの POP3 に対応した MUA で同じ POP3 サーバーからメールを拾ってきた場合にも同様の時間がかかってますか?
はい。
挙げた例は、fetchmail+procmail+POP3を使っていて、10年くらい前に海外の小国に旅行した際の話です。ネットワークが遅いということもあり、3時間くらい端末の前にずっと座ってました。
/var/mail/${USER} を移動してftpで取ってきて一見落着しました。
あとは、5年くらい前にfetchmail+procmail+POP3で、地方都市のPOP3サーバに対してメールを取りにいったときも(メールの数が多いので)やはりそんな感じでした。3時間というわけではないですが、取得毎に数分くらいは待ってしました。
最近は、(個人では)東京住まいで東京にあるデータセンタにメールを取りにいくのでRTTは低いですし、購読しているMLの数もずいぶん減りました。そして何より、常時接続されていますので、遅さを体感する機会は少なくなっていますが、それでも、遅さを感じることはあります。
例えば、今の会社のメールサーバは、某国にありIMAPでアクセスしていますが、長期休暇で1週間メーラを起動しないで初出社したときには、全てのメールが受信されるまでにコーヒが飲める程度には時間がかかりますね。ftpで転送したらどうってことのない転送量なんでしょうけれども。
最近のPOP3/IMAPクライアントは複数のメールの取得を同時にリクエストするのでしょうか?そもそもプロトコルデザイン上、同時にリクエストはできるのでしょうか?
サーバー側の実装の話とか、ファイルシステムとかの話もありまして……。 Solaris のような sync mount 大前提のシステムでそのまま Maildir を利用し、大量に新着メールをため込んでいる場合 Maildir/new → Maildir/cur (だったかな?) の移動のために長時間待たされる場合があります。こういうパターンでは、プロトコルどうこうという話にはなりません。
# テストで 4 万通流し込もうとして、うっかり 40 万通流し込んだら 4、5 時間 MUA が応答しませんでした……。
メールの場合はバックエンドがどのようになっているかは不定です。必ずしも各ユーザーのメールがファイルに落ちているとは限りません。 また、IMAP では共有フォルダも参照できます。これを利用する場合、それこそ 1 ファイルに確定できませんし、ローカルにコピーするのは不適切ですね。
また、IMAP では要求と応答は非同期で行うことが可能です。HTTP のパイプライニングと同様に、応答が戻ってくる前に要求を出せます。
それらとは別にサーバーへ ssh 接続ができるのであれば、-C を付けてポートフォワードを行うことで圧縮をかける事も可能ですね。
ほかの人も書いているけど、それは、POP3 の話じゃなくて 特定の POP3 サーバーかクライアントの実装の話ですよね。
POP3 サーバーを Dovecot にでもして、メールボックス形式を maildir か何か(mbox 以外) にでもしたらどうですか。(Qpopper あたりを利用して遅いとか言っているんじゃないかと邪推 :-p)
> 同時にメールを取得して同時にメールをフラッシュできるようなプロトコルが
「メールのフラッシュ」って、具体的にどこのどんな動作のことを指していますか?
POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく動作するものなのでしょうか?
また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?
もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、指摘の通り、特定のメーラの実装の話です。
「メールのフラッシュ」とは、RETRを実行した後に実行するDELEおよびその完了動作を指して使っています。
> POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、> RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく> 動作するものなのでしょうか?
諸々の事情でたぶん動作するでしょうが、意味はないでしょう。
それよりも、どうしてこれ↑とこれ↓から、
> また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?
これ↓が導き出されるんですか?
> もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、> 指摘の通り、特定のメーラの実装の話です。
あなたの書いた /var/mail/${USER} とか、procmail は POP3 仕様ではないので、mbox 形式のメールボックスのフラッシュが遅いだとか、procmail の fork が遅いだのってのは、POP3 とは関係ありません。
POP3 のプロトコル仕様を勉強してくださいな。
thorin氏が#1672793 [srad.jp]で書いたように、POP3はpipeline capabilityが無いと遅くなりますし、POP3のデータをftpで転送すりゃ速度は出るでしょう。POP3にpipeline capabilityがあったとしてもfetchmailでprocmailのフィルタを通すなど、(車1台1台がハイウエイの料金を支払うときのように)1通1通のメールに対しシーケンシャルに処理行なえば、メール毎にTCPは1セグメントから転送を開始しますので、(車が料金所で混雑するように)POP3のプロトコルの性能上処理は遅くなるでしょう。これは、POP3(というか、HTTPしかり、複数のオブジェクトを取ってくる必要のあるプロトコルをTCP上で動作させた場合に発生する)固有の問題です。(メールを/var/mail/${USER}のように)単一のオブジェクトとみなしてftpで転送する場合には、この現象は発生しません。
昨今のネットワークのシステム設計では、このようなみかけのネットワークレイテンシィをいかに抑制するかが課題となっていると思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:3, 興味深い)
昨今のネットワークの性能からすると、HTTPやPOP3はとても性能が悪いです。
メール容量にしたら、たった2MBほどなんでftpで/var/mail/${USER} を持ってきたら
(帯域次第ではあるが)一瞬で転送が終るのだが、POP3を通すと、
1. メールを取得, 2. メールのフラッシュ, 3. ローカルの処理待ち
を届いたメールの数だけ繰り返す、なおかつ、その度にprocmailをforkするんで
遅くて仕方がないです。
ネットワークの遅延を100ms, サーバのレスポンスを50ms, procmailのforkと処理の
時間を100msとすると、1つのメールあたり250msかかることになり、2000通メールが
たまっていると、どれだけ帯域が広くても50秒以上の時間がかかることになる。
以上は簡単に計算した結果だが、TCPの初期転送速度は非常に遅いので、メールの
サイズが1500バイトに収まらない場合、実際には、もっと遅くなってしまう。
例えば、30KBのメールが届いたとすると、サーバの負荷がどれだけ低くても、
最短でも5RTT(100ms*5RTT=500ms)がかかってしまうことになる。
1RTT: 1500
2RTT: 1500+3000=4500
3RTT: 4500+6000=10500
4RTT: 10,500+12,000=22,500
5RTT: 22,500+24,000>30,000
同時にメールを取得して同時にメールをフラッシュできるようなプロトコルが
あればPOPメールのフラッシュを待たなくてもよいと思うのだけど、最近のメール転送
プロトコルには、このようなPOP3の欠点を隠せるような設計が盛り込まれている
のでしょうか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2)
なので、POP を使うならメールを溜め込まないようにしましょう。
procmail 使ってなくても、概略同上。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
POP3 の欠陥じゃなく、POP3 を利用して procmail でローカルにデータを持ってくる場合の実装上の欠陥じゃないんですか? それ。
そこらの POP3 に対応した MUA で同じ POP3 サーバーからメールを拾ってきた場合にも同様の時間がかかってますか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2)
はい。
挙げた例は、fetchmail+procmail+POP3を使っていて、10年くらい前に
海外の小国に旅行した際の話です。ネットワークが遅いということもあり、
3時間くらい端末の前にずっと座ってました。
/var/mail/${USER} を移動してftpで取ってきて一見落着しました。
あとは、5年くらい前にfetchmail+procmail+POP3で、地方都市の
POP3サーバに対してメールを取りにいったときも(メールの数が
多いので)やはりそんな感じでした。3時間というわけではないですが、
取得毎に数分くらいは待ってしました。
最近は、(個人では)東京住まいで東京にあるデータセンタにメールを取り
にいくのでRTTは低いですし、購読しているMLの数もずいぶん減りました。
そして何より、常時接続されていますので、遅さを体感する機会は少なく
なっていますが、それでも、遅さを感じることはあります。
例えば、今の会社のメールサーバは、某国にありIMAPでアクセスして
いますが、長期休暇で1週間メーラを起動しないで初出社したときには、
全てのメールが受信されるまでにコーヒが飲める程度には時間がかかりますね。
ftpで転送したらどうってことのない転送量なんでしょうけれども。
最近のPOP3/IMAPクライアントは複数のメールの取得を同時にリクエストするのでしょうか?
そもそもプロトコルデザイン上、同時にリクエストはできるのでしょうか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
サーバー側の実装の話とか、ファイルシステムとかの話もありまして……。
Solaris のような sync mount 大前提のシステムでそのまま Maildir を利用し、大量に新着メールをため込んでいる場合 Maildir/new → Maildir/cur (だったかな?) の移動のために長時間待たされる場合があります。こういうパターンでは、プロトコルどうこうという話にはなりません。
# テストで 4 万通流し込もうとして、うっかり 40 万通流し込んだら 4、5 時間 MUA が応答しませんでした……。
メールの場合はバックエンドがどのようになっているかは不定です。必ずしも各ユーザーのメールがファイルに落ちているとは限りません。
また、IMAP では共有フォルダも参照できます。これを利用する場合、それこそ 1 ファイルに確定できませんし、ローカルにコピーするのは不適切ですね。
また、IMAP では要求と応答は非同期で行うことが可能です。HTTP のパイプライニングと同様に、応答が戻ってくる前に要求を出せます。
それらとは別にサーバーへ ssh 接続ができるのであれば、-C を付けてポートフォワードを行うことで圧縮をかける事も可能ですね。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
ほかの人も書いているけど、それは、
POP3 の話じゃなくて 特定の POP3 サーバーかクライアントの実装の話ですよね。
POP3 サーバーを Dovecot にでもして、メールボックス形式を maildir か何か
(mbox 以外) にでもしたらどうですか。
(Qpopper あたりを利用して遅いとか言っているんじゃないかと邪推 :-p)
> 同時にメールを取得して同時にメールをフラッシュできるようなプロトコルが
「メールのフラッシュ」って、具体的にどこのどんな動作のことを指していますか?
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
動作するものなのでしょうか?
また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?
もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、
指摘の通り、特定のメーラの実装の話です。
「メールのフラッシュ」とは、RETRを実行した後に実行するDELEおよびその完了動作を指して
使っています。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2, すばらしい洞察)
> POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
> RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
> 動作するものなのでしょうか?
諸々の事情でたぶん動作するでしょうが、意味はないでしょう。
それよりも、どうしてこれ↑とこれ↓から、
> また、最近は実際にそのようなリクエストの出し方をしているメーラが多いのでしょうか?
これ↓が導き出されるんですか?
> もし、このようなリクエストの出し方ができるのであれば、プロトコルの限界ではなく、
> 指摘の通り、特定のメーラの実装の話です。
あなたの書いた /var/mail/${USER} とか、procmail は POP3 仕様ではないので、
mbox 形式のメールボックスのフラッシュが遅いだとか、procmail の fork が
遅いだのってのは、POP3 とは関係ありません。
POP3 のプロトコル仕様を勉強してくださいな。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2)
thorin氏が#1672793 [srad.jp]で書いたように、POP3はpipeline capabilityが無いと遅くなりますし、POP3のデータをftpで転送すりゃ速度は出るでしょう。POP3にpipeline capabilityがあったとしてもfetchmailでprocmailのフィルタを通すなど、(車1台1台がハイウエイの料金を支払うときのように)1通1通のメールに対しシーケンシャルに処理行なえば、メール毎にTCPは1セグメントから転送を開始しますので、(車が料金所で混雑するように)POP3のプロトコルの性能上処理は遅くなるでしょう。これは、POP3(というか、HTTPしかり、複数のオブジェクトを取ってくる必要のあるプロトコルをTCP上で動作させた場合に発生する)固有の問題です。(メールを/var/mail/${USER}のように)単一のオブジェクトとみなしてftpで転送する場合には、この現象は発生しません。
昨今のネットワークのシステム設計では、このようなみかけのネットワークレイテンシィをいかに抑制するかが課題となっていると思います。
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:2, 参考になる)
> RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
> 動作するものなのでしょうか?
昔 POP3 server の実装やりました。
これは POP3 server と client の実装によります。
規格的に言うと POP3 server と POP3 client の両方が PIPELINING capability を実装している場合には上記動作が可能になります。(cf. RFC2449)
ということで規格の方はずっと昔に既に拡張済み。
# それよりも(世の中にあふれている?)行バッファリングでパケットを送る駄目 POP3 server の方が本当の問題だと思う
Re:HTTPだけじゃなくてPOP3も高速化してほしいな (スコア:1)
そーじゃなきゃRSETでキャンセルできない。