Hi, Mark and others.

On Thu, 30 Nov 2006, Mark Crispin wrote:

Fortunately, the primary cost is one-time per mailbox, as long as subsequent access is through the new code. If the mailbox is subsequently accessed via old code you may experience the large hit again. As this is an issue for you, I strongly recommend that you try the latest imap-2006d development snapshot, as there are performance improvements for traditional UNIX format with UIDPLUS in that version.

Using imapd-2006d (376) and pine with the new c-client has helped a bit. It is still noticably slower than imapd-2004g, but in a nearly-tolerable way.

I don't think that there is any legacy code getting in the way here, as for the purpose of testing I'm using *only* these versions of the server and client. In some cases, procmail may be delivering directly to one or more of my problem mailboxes; would that have a similar impact?

If you don't mind explaining, what is going on that causes the slowdown? Do the UIDPLUS ids have to be re-evaluated for the whole mailbox if a message is found without one?

There is a smaller hit with traditional UNIX format that is unavoidable. It should be much less costly than the big hit; however, if you really have 940MB traditional UNIX mailbox format mailboxes you should seriously consider using another format for other reasons.

In my personal case, these are my exception mailboxes; mostly write-only, and cleared out a couple times a year. However, I know that I have some users who have primary mailboxes of this size and worse.

I will say that the mix-format mailboxes I've been testing are working quite well, and very fast, aside from one situation where copying 1000 messages from a unix-format mailbox to a mix mailbox w/ pine took 25 minutes. I'm assuming that was a fluke, and will ignore it. :) As for the mix format more generally, are you confident enough in it to advise me to recommend it to my users when they complain about their mailboxes being slow?

  Thanks for your help, and for all your efforts over the years.

Chris
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to