Bug 2513 - many operations are very slow
Summary: many operations are very slow
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: Folders/IMAP (show other bugs)
Version: 3.7.9
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2011-10-05 20:24 CEST by Pierre Ossman
Modified: 2011-12-19 20:09 CET (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Ossman 2011-10-05 20:24:26 CEST
I've had this problem basically since day one, but I feel it has been getting worse (size of mailbox?) and I did some digging today.

My basic problem is that some operations in claws are just terribly slow, and for no apparent reason. It affects most operations, like fetching, opening and deleting mail. It's often not noticable on single mails, but when you start doing a lot of things, then it just takes forever to complete.

The most prominent case is the simple operation of scanning a mailbox. Looking at the log, it does things in chunks of 50 mails, and that takes 2 seconds. But it just spends at most a few hundred milliseconds to get those 50 mails. The rest of the time it is just sitting there, doing nothing.

I did strace on the server. It hands out the emails quickly and then goes back to waiting for the next command. Did an strace of claws. It fetches the emails, then just goes back to select and waits for a timeout.

Something is very fishy here, but I don't think I can get any further without digging into the code.
Comment 1 Pierre Ossman 2011-10-05 20:34:53 CEST
Sorry, misread the log files. It seems claws is waiting for the mail server:

[20:32:13] IMAP4> 454 UID FETCH 249:298 (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (Date From To Cc Subject Message-ID References In-Reply-To)]) 
[20:32:14] IMAP4< [FETCH data - 8192 bytes]
[20:32:15] IMAP4< [FETCH data - 8192 bytes]
[20:32:15] IMAP4< [FETCH data - 6226 bytes]
[20:32:15] IMAP4> 455 UID FETCH 199:248 (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (Date From To Cc Subject Message-ID References In-Reply-To)]) 
[20:32:16] IMAP4< [FETCH data - 8192 bytes]
[20:32:16] IMAP4< [FETCH data - 8192 bytes]
[20:32:16] IMAP4< [FETCH data - 5130 bytes]

But the strace on the imap server (courier) shows that it is sending out the data right away. I guess nagle is to blame?
Comment 2 Pierre Ossman 2011-10-05 21:44:23 CEST
Nagle doesn't seem to be it either. Looking at a packet trace, things just get more confusing. The delay that's seen on the higher level isn't present there. Instead, each packet from the server is sent at a 200 ms interval (with an ACK back between each packet). Given that it takes 10-20 of these packets to assemble the complete response, it adds up to the total delay seen.

Ideas? :/
Comment 3 Colin Leroy 2011-10-05 22:33:07 CEST
Not really. An interesting test would be to test another IMAP daemon (and/or another kernel ?), and to test another client (One that doesn't open multiple connections to the server).
Comment 4 Pierre Ossman 2011-10-06 08:25:10 CEST
Any suggestions for such a client? The two alternative clients off the top of my head are Thunderbird and Evolution, and I think both of them open quite a few connections.
Comment 5 Colin Leroy 2011-10-06 09:08:56 CEST
Try Mutt, maybe :)
Comment 6 Pierre Ossman 2011-12-19 20:05:23 CET
Problem solved! Turned out this was the old kvm/ipv6/segment offloading bug. I managed to find it as Android did not cope as well with it as a regular Linux system.

I'll just go ahead and close this issue. :)
Comment 7 Colin Leroy 2011-12-19 20:09:17 CET
Thanks for reporting back !