受信の速度 - 秀丸メール情報交換会議室 - スレッド04715, 2002/01/09

受信の速度

kurumagaeshi さん　02/01/09 05:13

今日はじめて鶴亀を使いました。
受信の速度についての疑問です。（既出なら、御免なさい。m（__）m）

mailerとしては、「Datula」と「Becky!2」を使っています。
「鶴亀」でのmails受信速度が、「Datula」、「Becky!2」に比べて
ずいぶん遅いと感じます。何か設定を変えると早くなるのでしょうか？

・mailをserverに残すという設定をしているので、
ほとんどおなじ環境で受信速度の比較が出来ます。
おおざっぱにいうと、3倍くらい時間がかかる感じです。
・環境：フレッツADSL（約1,000kbps）
PentiumIII850MHz　*2（DualCPU)、RAM　512MB；Windows2000prof.

RE:04715 受信の速度

kurumagaeshi さん　02/01/09 08:52

>「鶴亀」でのmails受信速度が、「Datula」、「Becky!2」に比べて
>ずいぶん遅いと感じます。何か設定を変えると早くなるのでしょうか？

設定は、必須項目以外はdefaultです。
受信するmailsの通数が多いほど遅い感じがします。
またその場合、後に行くほどとくに遅くなるようです。

RE:04716 受信の速度

秀まるお2 さん　02/01/09 14:53

>受信するmailsの通数が多いほど遅い感じがします。
>またその場合、後に行くほどとくに遅くなるようです。

　僕の所のLAN環境でテストした限りはそんなに差は無いように思いましたが、
たしかに少し鶴亀メールの方が遅いような気がします。

　少し遅い原因は、たぶん、Windows2000における、非同期ソケットと同期ソ
ケットの性能差かと思います。鶴亀メールは非同期ソケットを使っていますが、
Becky!2は同期ソケットを使っているようです。

　（っというのは、タスクマネージャでスレッド個数を見ていると、Becky!で
送受信した時にスレッド数が増えることで確認できます）

　はたしてこれが原因で３倍も差が付くことがあるのかどうか分かりませんが、
せっかくなので鶴亀メール側でも同期訴権とを使うように（＝マルチスレッド
化するように）修正します。

　ちょっと改造量が多くなるかもしれなくて怖いけど…。まぁ、秀ネットシス
テムでマルチスレッドには慣れているのでたぶん大丈夫です。

RE:04720 受信の速度

秀まるお2 さん　02/01/09 14:58

　っと思ったんですが、今バグ報告が溜まっているのでやっぱり後回しにさせ
ていただきます。

　（メールの分割送信はさらにその後に）

RE:04716 受信の速度

秀まるお2 さん　02/01/10 10:22

　さらにコメントしてしまいますが、もしかしてアンチウィルスソフトを常駐さ
せておられるのでしょうか？。だとしたら、一度アンチウィルスソフトを終了さ
せた状態での受信速度を見てみてほしいです。

　もしかすると、それで速くなるかもしれないです。

RE:04729 受信の速度

kurumagaeshi さん　02/01/11 06:42

>　さらにコメントしてしまいますが、もしかしてアンチウィルスソフトを常駐さ
>せておられるのでしょうか？。

常駐させていません。

なお、バグではないので、この件の対応はいそぎません。

それにしても、こういう経験はほかのユーザの方にはないのでしょうか？

RE:04732 受信の速度

PATIO さん　02/01/11 11:15

>それにしても、こういう経験はほかのユーザの方にはないのでしょうか？

私の場合、他のメールソフトを平行して使っていませんし、
比べてみようと思うほど、遅く感じたことはないので。
ちなみに言われている「Datula」も「Becky!2」も
使ったことがないです。
使ったことがあるのは、WinbiffとAL_MAILとOEぐらいですが、
Winbiffもとっくにおさらばしているので。
比較のしようがないです。
このためにわざわざインストールする気にもなれませんし。

RE:04736 受信の速度

秀まるお2 さん　02/01/11 11:44

　実はすでに同期ソケットを使ってマルチスレッドで受信する処理を作ったんで
すが、速度はまったく同じでした。

　ただし、ADSLの環境ではまた違ってくるのかもしれません。ということで次の
バージョンにて様子を見てほしいです。＞kurumagaeshi様へ

　鶴亀メールが特に遅い理由として、他に思い当たるのは、スレッド表示の時に
現在のスレッドに新しく受信したメールを追加する処理があります。現在のスレ
ッド表示に５０００個くらいメールがあったりすると、そこのどこにメールを追
加するのか計算するのもけっこう大変で、さらに、Windowsのツリービューコン
トロールにアイテムを追加すると、そのときの画面の表示が非常に重いです。

　しいて、この辺の処理を受信速度に影響しないように、さらなるマルチスレッ
ド化なり、あるいは受信解析する前に次のメールのRETRコマンドを送ってしまう
手もありますが、…。ちょっと考えてみます。

RE:04732 受信の速度

マイケル2 さん　02/01/11 12:27

マイケルです。

kurumagaeshiさんの今朝 6時42分の
“RE 04729 受信の速度”について：
====

>それにしても、こういう経験はほかのユーザの方にはないのでしょうか？

私の方では鶴亀が特に遅いという認識はありません。なぜだろう？

試しに Becky!2 と AL-Mail、Shuriken Pro それに鶴亀で比較して
みましたが、体感的に差は感じませんでした。

設定は Becky! などは「サーバにメールを残す」にして受信。最終
的に鶴亀で受信して削除するといった具合です。
メールは 1KB 強のが30通ほどサーバにある状態でやってみました。
なお、設定はいずれのメーラも“一覧表示”です。

ＯＳは Win98, WinMe, WinXP とで数度やってみましたけど、体感的
にはどのＯＳでも同じようなものでした。

接続環境は eAccess + @nifty 1.5Mbps（実質的には接続時に
800Kbps 程度）
・CPU: 330-550MHz
・RAM: 128-384MB
・テストしたサーバ: venus.dti.ne.jp

# Becky! などでは、メールの送受信中にサーバとのやり取りが
# （たぶん）見られないのが、なんだか不安です。

---
TuruKame Ver.1.58, Hidemaru Ver.3.11

RE:04715 受信の速度

s_yam さん　02/01/11 14:09

>mailerとしては、「Datula」と「Becky!2」を使っています。
>「鶴亀」でのmails受信速度が、「Datula」、「Becky!2」に比べて
>ずいぶん遅いと感じます。何か設定を変えると早くなるのでしょうか？

　僕もたまに他のソフトと比較して遅いような気がすることが
あります。
　勘では、受信してもサーバに残す設定にしている場合に、
サーバに200通ぐらい残っている状態で、鶴亀で取り込んで
いないメールが 2、3通といった状況で受信をすると
そういった現象が起きないでしょうか。

　取り込んでいないメールを判断する方法が違っているの
では？と思います。(UIDL がどうとか・・・)
　ログを解析したりしているわけではありませんので
間違っていたらごめんなさい。

RE:04740 受信の速度

Firak さん　02/01/11 14:30

ふぃらくです

>
>試しに Becky!2 と AL-Mail、Shuriken Pro それに鶴亀で比較して
>みましたが、体感的に差は感じませんでした。
>
　僕の場合、AL-Mail　からの移行直後、実用上問題では
ありませんでしたが、遅くなったと感じたことを記憶してい
ます。
　当時、フォルダの設定を「１メール１ファイル」に設定して
いたので、それが原因かもしれません。

　今は、Ａｌ?ｍａｉｌをしまいこんでしまいましたので、現時点
では、比較ができません。

RE:04743 受信の速度

秀まるお2 さん　02/01/11 15:40

>　勘では、受信してもサーバに残す設定にしている場合に、
>サーバに200通ぐらい残っている状態で、鶴亀で取り込んで
>いないメールが 2、3通といった状況で受信をすると
>そういった現象が起きないでしょうか。

　受信済みメールかどうかについてはUIDL文字列の比較をしますが、これが特に
遅いことは無いはずです。

　アカウント毎フォルダにあるUIDL.binファイルが大きくなるとその分比較に時
間がかかることはありますけど、せいぜい何キロバイト程度にしかならないはず
なので、一瞬で検索しおわるはずです。？？？

　しいて、鶴亀メールが他のメールソフトと違うと言えば、UIDLコマンドとLIST
コマンドの送る順番が違いますけど…。普通はLISTコマンドを先に送るようなの
で、鶴亀メールもそのように修正してみます。

■お願い：
　今度お暇でしたら、送受信中に具体的にどの部分が遅いか、観察してみてほし
いです。さらに遅い箇所が分かった時は、できればCPU使用率のメーターなんか
も見てみてほしいです。遅いときのCPU使用率が100%になってるようなら鶴亀
メールの内部処理で時間がかかってるんだと思います。

---------
　ちなみに手元のバージョンでいろいろ試してる所ですが、現状は、

　１．メールを受信する。
　２．受信解析してファイルに保存する。
　３．画面上のメール一覧にメールを追加する。
　４．次のコマンド（RETRコマンドやDELEコマンド）を送る。

　となってますが、これを、

　１．メールを受信する。
　２．受信解析してファイルに保存する。
　３．次のコマンド（RETRコマンドやDELEコマンド）を送る。
　４．画面上のメール一覧にメールを追加する。

　と変えてみました。結果、スレッド表示の時にわずかですが受信速度が速くな
りました。

　さらに、２．の受信解析をRETRコマンドの後にする作戦も可能なので、それも
やってみます。（次のコマンドがDELEで無ければ可能なので）

RE:04746 受信の速度

秀まるお2 さん　02/01/11 16:46

　kurumagaeshiさんの「後になればなるほど遅くなる」という話で１つ思いつき
ましたが、送受信のやりとり記録を送受信中ダイアログボックスに表示するのに
もしかしたら時間がかかるのかもしれないです。

　というのは、後になればなるほど、あそこのエディットコントロールの内容が
大きくなって、そこのエディットコントロール側の処理がだんだん重くなるかも
しれないからです。

　ちなみにあそこの書き換えには、EM_SETSELメッセージとEM_REPLACESELメッ
セージを使っています。EM_SETSELでカーソルを末尾に移動して、EM_REPLACESEL
で文字列を挿入しています。

　何か、kurumagaeshiさんの所でエディットコントロールの動作を遅くするよう
な常駐ソフト類を使っているなんてことは無いですかね？。

　どっちにしても、その部分も調べてみます。

----------------
　次の鶴亀メールは送受信関係の処理がかなりいじられているので、当分の間こ
ちらで安定テストをした上で、さらにβ版という形でアップロードさせていただ
きます。

RE:04746 受信の速度

s_yam さん　02/01/11 17:06

>　受信済みメールかどうかについてはUIDL文字列の比較をしますが、これが特に
>遅いことは無いはずです。

　元の発言者と違うと思いますが、他のソフトと比較して本文の受信の
開始までに時間がかかっている気がしていました。

　nPOP のログと比較してみて分かったことを報告します。
鶴亀も nPOP もサーバに残す設定で、一度受信した後で新着メールが
来ていた場合です。

・鶴亀は、(デフォルトでは)UIDL、LIST ですべてのメールの
　情報を受信して、保存してある UIDL のリストと比較して
　新着がどこからかを判断し、受信を開始?。

・nPOP は、前回最後に受信したメッセージの番号? で
　TOP (番号) 0
　として前回最後に受信したメールの Message-Id: ヘッダ
　(X-UIDL: ヘッダかも) と比較して、同じであれば
　前回の番号+1 から受信を開始?。

　上のはソースコードを見ずに、あくまで想像で書いているので
信用しない方がよいと思いますが、最初に UIDL、LIST を送り
すべてのメッセージの情報を取得しているために時間がかかって
いるようです。
　nPOP は、UIDL を送っていませんでした。
　サーバにたくさんメールが残っている状態で、新着がなかった
場合の時間の差はかなりあると思います。

＃鶴亀メールに UIDL を使わない設定がありますけど、
＃試していません。

　LIST は、受信サイズを計算するために必要なんですよね。何通か
カウントするだけのソフトは送らなくて済みますよね。

　鶴亀メールは、モバイル環境などを想定して作られている
わけではないのでしょうか。

RE:04750 受信の速度

秀まるお2 さん　02/01/11 18:56

　nPOPについてはソースコードが公開されているので中身は調べれば分かります
が、LISTコマンドだけで新着メールの位置を判定するのはたぶん無理だと思いま
す。

　もし、完全に鶴亀メールでのみメールを受信するのだと仮定したら、例えば以
前1～10までメールがあって、それが1～20までに増えていたのなら、11～20番が
新着メールだと勝手に判断する作戦もできるかもしれないです。

　しかし、他のメールソフトでメールボックスをいじることもありえると思いま
す。例えば1～10までメールがあることを確認して、その後1～30までメールが増
えて、他のメールソフトで途中の適当な10通のメールが削除されていたとしたら、
やはり確実に新着メールの番号を知るにはUIDLコマンドを使うしか無いはずです。

　ということで、やはりUIDLコマンドとLISTコマンドはセットで呼ばないとダメ
だと思います。

RE:04739 受信の速度

kurumagaeshi さん　02/01/13 00:56

秀まるお２さん、お返事ありがとうございます。
現象を確認するため、再度やってみました。
「鶴亀」のヴァージョンは、最初の質問の時と同じく、「v1.57」です。

念のために、「鶴亀」をアンインストールし、サーバのメールを
そっくり読み込むという方法で行いました。（メールはサーバに残す。）
1）メールのデータ：
3,217通、全体で12,792KB
2)「鶴亀」での受信：１アカウントのみ。メール一覧を表示。
スレッド表示せず。
全部受信するまでの時間：2時間16分
3)「鶴亀」での受信：１アカウントのみ。画面はアカウント作成直後の
状態。（ほとんど何も表示されていない。）
全部受信するまでの時間：1時間50分。（メールデータは同じ）
3)Becky!2で受信。（画面は、2)に近い状態。）
13分30秒。（もちろん、メールデータは、同じ）

全体の時間としては、「鶴亀」は、ずいぶんBecky!2より遅いと思います。
ただし、最初の60通は20秒くらいで受信できます。
受信したメールの「通数が多くなると、受信速度が遅くなり」
1000通目あたりだと、1秒/通くらい、3000通あたりだと、7秒/通くらい
です。

##
Becky!2は、はじめも途中も終わりの方も、ほぼ同じ速度で
受信できています。

##
はじめの100通くらいでは、Becky!2との差を感じません！！
3000通ものメールを一度に受信することは、極めて稀なことですので
実用上特に問題にはならないように思います。
バグでもないので、これ以上追求していただく必要は無いと思います。
ただし、秀まるお２さんがもっと突き詰めたいとお考えなら、
テストはいたします。

##補足：
・メールデータは、DebianGNU/LINUXの世界各国のMLからのものです。
ほとんどのメールサイズが、2.5KB～5KBくらいです。途中にデカいメール
などはありません。
・環境：PentiumIII850MHz*2（DualCPU）RAM512MB；Windows2000pro
FLETS　ADSL（速度約1,000kbps）

>次のバージョンにて様子を見てほしいです。＞kurumagaeshi様へ

まだやってません。が、やる必要ありますか？

>鶴亀メールが特に遅い理由として、他に思い当たるのは、スレッド表示

上にあげた結果は、スレッド表示無しの場合です。

以上

RE:04775 受信の速度

kurumagaeshi さん　02/01/13 07:57

Datulaでもやってみました。
方法、メールデータ、環境は同じです。

1）メールのデータ：
3,217通、全体で12,792KB
2)Daulaでの受信：１アカウントのみ。メール一覧を表示。
全部受信するまでの時間：10分30秒。
（2回行いましたが、ほぼ同じ結果です。）

Datulaでも、はじめも途中も終わりの方も、ほぼ同じ速度で
受信できています。

##（補足）この場合の「メール一覧表示」について：
メール受信中は、読み込んだ順序で表示されていますが
受信が終わった瞬間に、一瞬にしてスレッド表示されます。
これは、Datulaのデフォルトの設定です。

RE:04775 受信の速度

kurumagaeshi さん　02/01/13 23:55

劇的にスピードアップしたのですが、新たな問題が・・・・。

たまたま、別のスレッド：04778 UIDLが初期化される？？？？
で「アカウントごとの設定」=>「メールサーバー」=>「高度な設定」
=>「UIDLコマンドを使わない」　あたりの設定変更を示唆されました。

そこで、「UIDLコマンドを使わない」ことにしてやったところ：

「鶴亀」のヴァージョンは、最初の質問の時と同じく、「v1.57」です。
念のために、「鶴亀」をアンインストールし、サーバのメールを
そっくり読み込むという方法で行いました。（メールはサーバに残す。）
1）メールのデータ：
3,217通、全体で12,792KB
2)「鶴亀」での受信：１アカウントのみ。メール一覧を表示。
スレッド表示せず。
全部受信するまでの時間：11分5秒。

##
この速度は、Becky!2より速く、Datulaに迫るものです！！
しかも、はじめも途中も終わりの方も、ほぼ同じ速度で
受信できています。

##
こんなところの設定が大きく効いてくるなんて・・・・。

##
ただ、新たな問題がでてきました。
サーバに3000通あまりのメールが残っているのですが、それ以降、
受信時にいつでも（つまり、UIDLコマンドを使っても使わなくても）
この3000通あまりのメールを「空読み」しているような感じがします。
受信はしていないのですが、3000通受信しているのと同じくらい時間が
かかります。このあたり、Becky!2もDatulaも「ほんの1～2秒で終わり」
未受信のメールだけ選んで受信するのですが・・・。
何か設定を変えればよいのでしょうか？

RE:04739 受信の速度

kurumagaeshi さん　02/01/14 10:20

04787で報告したように,「UIDLコマンドを使わない」ように設定したら、
「劇的に」スピードアップしました！！
ただし、今は「重複受信」の問題が起きています。

RE:04791 受信の速度

秀まるお2 さん　02/01/14 23:53

　とりあえずここにコメントさせていただきますが、UIDLを使う設定のせいで遅
いそうで…。

　３０００通以上ものメールを一度に受信するテストは今までやったことがあり
ませんでした。

　非常に気になる症状なので、明日じっくり調査させていただきます。

RE:04787 受信の速度

秀まるお2 さん　02/01/15 00:11

>ただ、新たな問題がでてきました。
>サーバに3000通あまりのメールが残っているのですが、それ以降、
>受信時にいつでも（つまり、UIDLコマンドを使っても使わなくても）
>この3000通あまりのメールを「空読み」しているような感じがします。

　これはこれで仕様です。ということで、このようなケースでは、「UIDLを使
う」設定でないと実用に耐えないです。

　（このようなケースというのは、つまり、サーバー上にたくさんのメールを残
して運用する場合の話です）

RE:04800 受信の速度

秀まるお2 さん　02/01/15 11:09

　テストしてみたら原因が分かりました。

　具体的な話をさせていただくと、鶴亀メールは受信時にいっしょにリモート
メールの一覧も更新する作りなんですが、そこの処理が重くなっていました。
UIDLを使わない設定だとリモートメール一覧を更新しないので速く動作するよう
です。

　リモートメール一覧の更新の中でも、具体的にはファイル名の計算に時間がか
かっていました。そこのファイルは１メール１ファイルとなっていて、

　RemoteYYYYMMDD_nn.txt

　という形式のファイル名を生成するんですが、このnn部分を計算するのに
FindFirstFile関数をファイルの数だけループするようになっていて、メール数
が多くなるとこれにとんでもなく時間がかかってしまうようです。

　ということでさっそく修正させていただきます。

RE:04756 受信の速度

s_yam さん　02/01/15 12:13

>やはり確実に新着メールの番号を知るにはUIDLコマンドを使うしか無いはずです。

もちろん、最後に受信したメールとサーバ上の最後のメールの情報
(Message-Id や UIDL) が違ったときには、UIDLコマンドを使う
必要があります。nPOP でもそのように動作します。

ただ、先に最後のメールを確認するだけの方が、新着の有無を判断するときに
早いことの方が多いと思うので、サーバに残す設定のときは
新着の有無の判断にUIDLを使わなくてもよいのでは？ということです。

RE:04809 受信の速度

秀まるお2 さん　02/01/16 00:09

>もちろん、最後に受信したメールとサーバ上の最後のメールの情報
>(Message-Id や UIDL) が違ったときには、UIDLコマンドを使う
>必要があります。nPOP でもそのように動作します。

　最後のメールというと、たとえば１０通サーバー上にあったとしたら、１０通
目のメールってことですかね？。

　サーバー上に１０通メールがあって、１０通目のメールが過去の１０通目の
メールと一致していたならば、たしかに「新着メールなし」と判断してもいいよ
うな気がしますが、それはつまり、そこのメールサーバーは１番から１０番まで、
古いメールから順番に返すという前提での話になると思います。

　ま、とにかくnPOPがどうであれ、とりあえずこの辺は危険なのでいじらないで
おきます。

　ただでさえ、今の手元のバージョンはおもいっきり修正が入って危険なので、
しばらくテストしないとだめです。あー気が重い。

RE:04808 受信の速度

kurumagaeshi さん　02/01/24 20:46

秀まるお２さんこんにちは！

>　テストしてみたら原因が分かりました。
>　ということでさっそく修正させていただきます。

v1.59、「メールサーバ・受信の高速化」ON　にてやってみました。
「鶴亀」のヴァージョンは、最新版v1.59です。

念のために、「鶴亀」をアンインストールし、サーバのメールを
そっくり読み込むという方法で行いました。（メールはサーバに残す。）
1）メールのデータ：
2,624通、全体で10,635KB
2)「鶴亀」での受信：１アカウントのみ。メール一覧を表示。
スレッド表示せず。
全部受信するまでの時間：9分6秒
はじめも途中も終わりの方も、ほぼ同じ速度で受信できています。
3)Becky!2で受信。（画面は、2)に近い状態。）
12分30秒。（もちろん、メールデータは、同じ）
4)Datulaで受信。（画面は、2)に近い状態。）
9分58秒。（もちろん、メールデータは、同じ）

##
「鶴亀」が、Becky!2はもちろん、Datulaよりも高速に受信できるように
なりました！！！
どうもありがとうございます。

##補足：
・上記の「鶴亀」の場合、メール一覧を表示させていますが、
ほとんどスクロールしません。一方、Datulaの場合は、ずっと
スクロールしています。このあたりで、ちょっと時間の差がでたのかな？
とも思います。
・メールデータは、DebianGNU/LINUXの世界各国のMLからのものです。
ほとんどのメールサイズが、2.5KB～5KBくらいです。途中にデカいメール
などはありません。
・メールをサーバに残す場合、ボックスにはいってから最長30日間
という（ISPによる）制限があるので、当初よりメールの通数が若干減りましたが、
比較検証にはこれで十分だと思います。
・環境：PentiumIII850MHz*2（DualCPU）RAM512MB；Windows2000pro
FLETS　ADSL（速度約1,000kbps）