GNOME Bugzilla – Bug 719475
[IMAPx] Increase multi-fetch chunk size to 32KB
Last modified: 2014-05-27 06:41:23 UTC
I am using Evolution 3.10.2 (on Arch Linux 64bit) to connect to my University's MS Exchange 2010 server through IMAP+. Attachments take very long to download from the server. For example, I just received an E-Mail with a 24 MB attachment; downloading took at least 10 minutes (I wasn't at my computer the whole time until the download finished). While attachments are downloading, I see the "% downloaded" indicator counting up very, very slowly. After it has reached 100%, it will still take a long while for the attachment to actually be available. I have tried downloading the same attachment with Thunderbird on the same machine, and with K-9 Mail on my Android phone. In both cases, the file was available after about a second.
Weird, I do not see any reason why it would take evolution's IMAP+ that long, not from the IMAP+ point of view. Might it be, because you had some connection issues during evolution's run, but when trying with Thunderbird, the connection issues were gone, thus it downloaded the attachment (almost) instantly? You can retest this, when you search for a very large message at ~/.cache/evolution/mail/<imapx-account-uid>/ and delete it, which will redownload it the next time you select the message in evolution's UI. You can do this even with evolution running, if you'll not have the message selected.
Thanks for the reply. It's definitely not a connection issue. I've been having these issues for at least a year with Evolution, always. And never with other mail clients. When I'm at work, I'm only a few hundred meters away from the mail server, on the same network, connected over 100 Mbps LAN. I'd be happy to upload logs if you tell me how to produce them.
I tried some debugging on this, but I didn't find anything useful. The IMAP+ code uses a "multi-fetch" (as it calls it, data->use_multi_fetch in camel-imapx-server.c) which is used when the reported message size is greater than 20KB. In that case the message is read by 20KB chunks. I turned off the "multi-fetch", and even I've got a quicker download by 1/5 of the message the first time, the second time it took twice longer than with the "multi-fetch". You can turn on IMAP+ debugging, if you wish, but I do not expect there will be anything useful. The debugging can be turned on when running evolution from console by command: $ CAMEL_DEBUG=imapx evolution &>log.txt
Created attachment 276890 [details] Camel IMAP+ debug I'm also seeing this, also with IMAP+ connected to a local Exchange server - I thought this was a problem that affected any type of IMAP server in general with Evolution... Here's the type of log you suggested, I simply started Evolution with only that account active and double-clicked a message to start downloading it, then Ctrl+C after a few seconds.
Sorry for not having followed up on this. Milan's remark that he doesn't expect anything useful in the log was not exactly encouraging, and then I simply forgot about it. This is not a general Evolution-IMAP issue. I'm also using a Gmail account with Evolution, also over IMAP+, and there attachments download just as fast as with any other mail client. Milan, I guess multi-fetch is a compile time option? Could you tell me how to turn it off, then I will check whether this changes anything for me.
Oops, I missed the log attached, I'm sorry. Basically, it shows that it downloads a 200KB message by ~2.5KB chunks, which means less than 100-times asking the server for data. It can be that the server as such doesn't like it. (In reply to comment #5) > Milan, I guess multi-fetch is a compile time option? Could you tell me how to > turn it off, then I will check whether this changes anything for me. I think the disable of the multi-fetch is not a good idea and it's not even that simple. Rather increase the amount of data which can be downloaded at once. You can find the value here: https://git.gnome.org/browse/evolution-data-server/tree/camel/providers/imapx/camel-imapx-server.c#n66 When I want to make things super-slow, I change the value to 480, from its original 20480. The comment says it's in bits, which seams to be true, according to Jean-François' log.
(In reply to comment #6) > When I want to make things super-slow, I change the value to 480, from its > original 20480. The comment says it's in bits, which seams to be true, > according to Jean-François' log. I would increase it to 32KB, which is (32768 * 8), but it can be that some servers will not like value greater than 4KB (4096 * 8). Of course, some adaptability code would be the best.
I've just recompiled evolution-data-server 3.12.2 with MULTI_SIZE set to 32768 * 8 as per your recommendation, and attachments download MUCH faster. I just opened an e-mail with a 10 MB attachment and the file was ready within 10 seconds or so (I'm at home with a weak WiFi signal, so faster might not even be possible). Before recompiling, I closed Evolution after maybe 4 minutes, with the download at something like 30%.
Thank you for testing it. I increased the size to 32KB. I also briefly looked into the IMAP4 RFC and the value being used for partial fetching is more like a request, than a mandatory value, which can be clamp by the server when necessary, thus the note above "adaptability code" above is false. Created commit f8c6a1c in eds master (3.13.3+) [1] Created commit 10a21fa in eds evolution-data-server-3-12 (3.12.3+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=f8c6a1c