| |
6.84β9 で確認したところ、 2秒 固まる部分も治っており、
受信中に固まることを体感しなくなりました！
これにより、私が感じていた不都合は解消されました。
ありがとうございます！
> ちなみにこちらで１０万通サーバーに置いてテストしました。
> 前回別スレッドにした処理は、0.06秒、今回別スレッドにした処理も0.06秒程度
>しかこちらではかかってなかったりします。
> なんで２秒もかかるのか・・・。
>
想像ですが、 UIDL.bin の並びと UIDL コマンドでダウンロードした UniqueId の並
びの問題ではないかと思うのですよね。
Office 365 の Exchange Online を使っているのですが、 Exchange Online の Uniq
ueId は 十進数の数値で表され、 UIDL コマンドでは十進数値としてソートされた状
態で取得されます。
一方 UIDL.bin のほうは 受信するたびに先頭に受信した順番に UID が追記されるよ
うですが、そのせいで頻繁にメールを受信する環境では UIDL.bin 内の UIDL の並び
順がきれいになりません。
例えば、 10分毎の定期受信で 3通ずつ メールを受信する場合、
UIDL コマンドで取得した UIDL は
先頭← ..., 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009 →末尾
と並びますが、 UIDL.bin では、
先頭← 1007, 1008, 1009, 1004, 1005, 1006, 1001, 1002, 1003, 1000, ... →末尾
と並んでしまいます。
> Version 6.76の時に、その比較の処理を、新旧のUIDLでの並び順が似ているという
>か、１日単位で見た場合はほぼ同じであることを利用して高速化
>
これがどのような処理なのか想像してみたのですが、 上記の Exchange Online の U
ID と UIDL.bin 記録の仕様の組み合わせと、この高速化の処理の仕様の相性が悪い
のかもしれません。
dump.txt のログを出力する設定にしてみましたが、 UIDL解析中 (1) と (2) がそれ
ぞれ 2.5秒 ずつほどかかっていました。
12:10:24.227 R ...(3173315バイト)
12:10:24.227 (9611) UIDL解析中...
12:10:24.227 (10799) UIDL解析中...
12:10:26.549 (8850) will Recv_UpdateRemoteMailAtStartRetr
12:10:26.565 (8917) done Recv_UpdateRemoteMailAtStartRetr
12:10:26.565 (9611) UIDL解析(2)
12:10:26.565 (10799) (2)
12:10:29.149 (9611) 0 / 5 済み (0K / 309Kバイト)
試しに、 UIDL.bin を 以下のような PowerShell コードで、 日付ごとに UID が降
順になるように書き換えてみたところ、 30ms 程度とそれこそ劇的に早くなりました。
$uidl = Get-Content UIDL.bin -Encoding Ascii;
$list = New-Object 'System.Collections.Generic.List[uint64]';
$key = '';
$uidl | %{ if ($_ -match '^\*') { if ($key -ne '') { Write-Output $key; } $l
ist | Sort-Object -Descending | Write-Output; $key = $_; $list.Clear() } els
e { $list.Add([uint64]$_) } } -End { Write-Output $key; $list | Sort-Object
-Descending | Write-Output; } | Set-Content UIDL2.bin -Encoding Ascii;
12:15:44.942 R ...(3173660バイト)
12:15:44.958 (9611) UIDL解析中...
12:15:44.958 (10799) UIDL解析中...
12:15:44.975 (8850) will Recv_UpdateRemoteMailAtStartRetr
12:15:44.992 (8917) done Recv_UpdateRemoteMailAtStartRetr
12:15:44.992 (9611) UIDL解析(2)
12:15:44.992 (10799) (2)
12:15:45.024 (9611) 0 / 20 済み (0K / 1168Kバイト)
今後受信するメールについては、 メールを受信する順番と UIDL.bin に追記する順
番を逆にすることで、 低速になってしまうことを回避できるのではないかと想像し
ます。
Exchange Online は UIDL の順番がわかるので上記のような書き換えが可能でしたが、
汎用的に考えると UIDL の文字列からその順番を求めることはできないため、すで
に受信してしまったものを救う上手な手立ては思いつきません。
… UIDLの解析に時間がかかっている環境の場合、 1度だけ 「UIDL.bin の整理」 と
して、 UIDL.bin の日付ごとの並びを UIDL で取得した順番の逆順になるように書き
換えてみるとか…？うーむ。。。
もし、 UIDL.bin や UIDL コマンドの結果があるとより検証しやすいのであれば、
公開フォーラムおくのはちょっと憚られるものの、直接メールでお送りいたします。
|
|