K9mailで添付ファイルの取得がとてもとても遅い
Koji Arai
>メールを開くと「Downloading...」と表示が出て自動的に添付ファイルのダウンロードが始まるのですが
という記述を見る限り、v2.512日本語版についての記述ではないと思われる。
マーケットで公開されているv2.401ならばその通りだが、v2.512では、Downloading...という表示がでないし、メールを開いても
自動的にダウンロードは始まらない。
v2.512でも、ダウンロードが遅いのは確かだが、Openを行った後他の操作を継続して裏でダウンロードを継続させることができているっぽい。（た
だし、ボタンが凹んだままでバックグラウンドの動作がわかりずらい）
コミット 43332d08d5dc1b01ef9313208d13ab41becd56e3 の前後での動作確認が必要
Koji Arai
少し日曜プログラマから離れていたので遅くなりましたが、K-9 Mailの添付ファイル受信速度が遅い件です。
試しに、受信バッファサイズを適当に 1024バイトから10240バイトに増やしたところ、
エミュレータでGmailからの受信にて以下の結果になりました。
約365.4kBの添付ファイル（JPEG画像）の受信が
1024バイト→30秒
10240バイト→12秒
ソースは、enlarged-downloading-buffer-size ブランチに反映しています。
(http://github.com/jca02266/k9mail/commit/
af3942fb87db855528a2a7f2d4b67ec1e5e87fae)
自分の実機で少し評価したのちお試しでバイナリをビルドしようかと考えています。
# DoCoMo の3G回線って、実効回線速度ってどのくらい？
--
Koji Arai
--
Subscription settings: http://groups.google.com/group/k9mail_ja/subscribe?hl=ja
Koji Arai
すみませんちょっとした訂正。（また）ベースのコミット元がずれていたので再度コミットしなおしました。
> ソースは、enlarged-downloading-buffer-size ブランチに反映しています。
> (http://github.com/jca02266/k9mail/commit/
> af3942fb87db855528a2a7f2d4b67ec1e5e87fae)
http://github.com/jca02266/k9mail/commit/d3044863e
になってます（折り返されないようにURLを短く掲示)
# あくまでもタグ名で <http://github.com/jca02266/k9mail/commit/enlarged-
downloading-buffer-size> っとリンクを示した方がいいのかなあ？
Koji Arai
On 4月20日, 午後11:44, Koji Arai <jca02...@gmail.com> wrote:
> 試しに、受信バッファサイズを適当に 1024バイトから10240バイトに増やしたところ、
> エミュレータでGmailからの受信にて以下の結果になりました。
>
> 約365.4kBの添付ファイル（JPEG画像）の受信が
> 1024バイト→30秒
> 10240バイト→12秒
DL前に876kBと表示される添付ファイル(base64 encodeしたサイズと思われる)で
1024バイト→2分26秒
10240バイト→49秒
でした。
試しに固定値ではなくgetReceiveBufferSize()で取得したソケットのバッファサイズと
同じバッファサイズに揃えて試してみたのですが、大きな効果はありませんでした。(上記の876kBの条件で30秒くらい)
以下の通り、HT-03A では、87380 バイトのバッファサイズになるようです。(emulator も同じサイズでした)
$ adbht03a logcat | grep -i 'Receive.*Buffer.*Size'
I/k9 (17361): Receive Buffer Size: 87380
I/k9 (17361): Receive Buffer Size: 87380
I/k9 (17361): Receive Buffer Size: 87380
# なぜ3回表示されたかは調べてません。
# adbht03a コマンドは、adb -s xxxxのaliasです。
そういうわけで、10240の即値を採用して様子見しようと考えてます。
それぞれ1回ずつしか計測してないのでもうちょっと追試は使用と思いますが
送信バッファサイズやpop3はまた今度ということで、近いうちに
バイナリをアップする準備に入ろうかと思います。
今回試したソースは、以下
<http://github.com/jca02266/k9mail/commit/2a3e28f>
Koji Arai
On 4月22日, 午前12:05, Koji Arai <jca02...@gmail.com> wrote:
> 私個人のtwitterの方にも書きましたが実機(HT03Aで3G回線)で確認したところ。
> DL前に876kBと表示される添付ファイル(base64 encodeしたサイズと思われる)で
>
> 1024バイト→2分26秒
> 10240バイト→49秒
>
> でした。
あるようなないようないまいち不安定です。測定方法に問題がある気がしますので、本件は一旦取下げます。
期待させた人には申し訳ありません。
サーバ管理者の戯言
この件ですが、サーバの状態や通信状態なのが影響される気がしています。
なので、完全独立したサーバとの間で通信を行う必要がありそうです。
自社保有サーバをテスト的にお貸ししましょうか？
＃一応データセンター設置している、まともなサーバです。
＃とはいえ、客にも貸出しているので平日なら夜か土日でないとテストにならないかも
＃しれませんが。
まぁ私がテストすればいいって話ですね。スミマセン。
POP3サーバしかお貸し出来ませんけど。（笑）
ご存知かもしれませんが・・・
一般的なIMAP4の場合、通常Mailbox形式で保管されています。
Mailbox形式ですが、通常のファイルと同一の扱いになるので新着メールはnewフォルダに保管されます。当然ファイル数が少ないしIMAP4サーバ側もある程度キャッシュで動作しますので高速に動作する可能性が高いです。
しかしながら、既に受信済みファイルの場合アクセスされた場合既存ディレクトリのファイル数が1000件とかあると、その分速度が低下します。IMAP4サーバによっては既存メールへのアクセスは新着よりも優先度が低く設定されているケースもあるので、動作に変化があるかと思います。
再現テストって結構面倒なんですよねぇ。
受信バッファの拡大での対応ですが、欠点としては小さなファイルばかりだとロスが発生するので適当なサイズ（って何ってツッコミが・・・）にしないとってことはあります。