On Tue, Mar 11, 2003 at 10:47:23AM +0100, Andreas Aardal Hanssen wrote: > On Mon, 10 Mar 2003, Moe Wibble wrote: > >Hello everybody, > >I have come across bincimap recently and was instantly > >attracted by its slim design. > >I actually liked it so much that I attempted to migrate our cyrus > >imap-server to bincimap today. Unfornationally, after spending a couple > >hours on converting the cyrus database to something maildir-like, > >I was very disappointed by bincimaps poor performance on large folders. > >Is it really that slow or is it my fault? > >Opening a folder with ~12000 mails takes over 10min to complete and > >bincimap pretty much clogs up the machine while doing so. > > Opening a folder can be done in two ways - either just open it with > SELECT, or open it and download all message headers. Opening a folder with > 12000 messages (my qmail folder is that big) takes just a second or two > with Binc IMAP. > > Mozilla downloads all message headers the first time you connect to a new > server. This download will take just as long time with any IMAP server > that has little overhead with parsing the mime documents. The main > bottleneck is the bandwidth of your Internet connection. Downloading 12000 > message headers might means several megabytes travel across the network. > > After you opened the 12000 message folder, if you quit mozilla and start > up again, was is equally slow to open the same folder again?
First of all thanks for your reply (also to Ketil and Charlie). I think I have spotted the problem. The configuration value of "transfer buffer size" has heavy impact on performance here. The default value (about 8k) gave me the weak performance I reported. Raising the value made it even worse. A colleague of mine then suggested to make it equal to the hosts pagesize (4k), which noticably speeded things up. I tried lowering the value even more (now I have transfer buffer size = 1024) et wallah; bincimap now delivers about 300 headers/sec to mutt for any folder. Well, I'll have to keep on investigating on this one... :) regards -- MW
