| Summary | too much IMAP traffic with IMP 4 |
| Queue | IMP |
| Queue Version | 4.3 |
| Type | Bug |
| State | Not A Bug |
| Priority | 2. Medium |
| Owners | |
| Requester | earl.fogel (at) usask (dot) ca |
| Created | 12/18/2008 (6042 days ago) |
| Due | |
| Updated | 12/18/2008 (6042 days ago) |
| Assigned | |
| Resolved | 12/18/2008 (6042 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Not A Bug
stuff than IMP 3, so there's going to be some level of extra IMP
traffic.
#2- You are almost certainly not using caching. If you care aboutperformance at all, you need to be caching IMAP data.
#3- As for the terribleness of the IMAP commands actually sent to theserver - this has nothing to do with the Horde project. We use the
c-client IMAP library - it is what is sending the commands to the
server. I won't even begin to describe the inefficiencies of the IMAP
commands it sends. This is why an entirely new IMAP library has been
written for IMP 5.
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ too much IMAP traffic with IMP 4
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
hardware, same operating system, same apache, same php. With IMP 3,
listing a mailbox takes less than 1 second. With IMP 4 it takes 5
seconds.
So, I used tcpdump to trace the IMAP traffic, and found IMP 4 is doing
far too much work.
My test mailbox has about 1000 messages, IMP is configured to display
100 per page.
With this setup, IMP 3 does 6 IMAP FETCHes, IMP 4 does 305 IMAP
FETCHes. In addition, it looks like IMP 4 is fetching the same group
of messages (106:125) over and over again.
IMP 3 IMAP Trace:
LOGIN ...
CAPABILITY
SELECT bulk
LSUB "" *
LIST "" INBOX
FETCH 1:20 (UID ENVELOPE BODY PEEK[HEADER.FIELDS (Newsgroups
Content-MD5 Content-Disposition Content-Language Content-Location
Followup-To References)] INTERNALDATE RFC822 SIZE FLAGS)
FETCH 21:1299 (UID INTERNALDATE RFC822 SIZE FLAGS)
SEARCH UNSEEN
FETCH 21:40 ...
FETCH 41,42:61
FETCH 62,63:82
FETCH 83,84:103
LOGOUT
IMP 4 IMAP Trace:
LOGIN ...
CAPABILITY
STATUS bulk ((MESSAGES.RECENT.UNSEEN.UIDNEXT.UIDVALIDITY)
EXAMINE bulk
UID FETCH 1 UID
UID FETCH 2 UID
UID FETCH 3 UID
...
UID FETCH 98 UID
UID FETCH 99 UID
UID FETCH 100 UID
FETCH.1,2:21.(ENVELOPE.BODY.PEEK[HEADER.FIELDS.(Newsgroups.Content-MD5.Content-Disposition.Content-Language.Content-Location.Followup-To.References)].INTERNALDATE.RFC822.SIZE.FLAGS)
FETCH 22,23:42 ...
FETCH 43,44:63 ...
FETCH 64,65:84 ...
FETCH 85,86:105 ...
GETQUOTAROOT bulk
FETCH 1,106:125 (BODYSTRUCTURE.FLAGS)
FETCH 1 BODY PEEK[HEADER]
FETCH 2,106:125 (BODYSTRUCTURE.FLAGS)
FETCH 2 BODY PEEK[HEADER]
FETCH 3,106:125 (BODYSTRUCTURE.FLAGS)
FETCH 3 BODY PEEK[HEADER]
...
FETCH 99,106:125 (BODYSTRUCTURE.FLAGS)
FETCH 99 BODY PEEK[HEADER]
FETCH 100,106:125 (BODYSTRUCTURE.FLAGS)
FETCH 100 BODY PEEK[HEADER]
LOGOUT