Dominic Amann wrote: > Paul J Stevens wrote: > >> Dominic Amann wrote: >> >> >>> Bar date and memory address being different. The system is working, >>> albeit with performance issues and occasional timeouts with 150 users >>> using imap. >>> >> >> >> There are several known performance issues with dbmail's imap. Check >> the wiki so >> see where the 2.1 series and beyond is heading. >> >> >> >> >> > The wiki seems almost empty 'cept for headings of wholesale code-method > changes (new api for message retrieval, header caching tables blah blah > blah). I can not see how these changes would impact my users (they > almost never search), and using a new api may introduce as many bugs as > it resolves.
Mmmm, imo searches are rarely used because no free imap server does them any way near fast enough. Your problems though are at the heart of why I took dbmail upon myself. I didn't write dbmail. But the problems you face are why I'm trying to fix the code. Your clients take 20 minutes to append a message to the sent folder because the server just hung up, and the client won't reconnect for 20 minutes or just can't get a new connection. Long delays for loading message bodies are often also an indication that the server crashed out, or that the mime parser just got into a runaway loop. That code has gone unmaintained since before 1.2 afaik. And for some pretty good (or rather bad) reasons. So yes: fixing problems will cause new bugs, but at least they will be different (hopefully less serious) bugs. Also, there will be someone who cares enough to fix them, or else be readable, well designed, supported by regression tests so someone else can fix them. > The performance issues are not ones of typical performance (you know, > several seconds to do things). They are ones where progress dialogs stay > on the user's machines for 20 minutes just copying a message to the sent > folder. The server is showing .04% CPU utilization. You're describing a fatal bug. Calling that a performance issue, is a matter of definition I imagine. Still, once you get past those fatal server crashes, people will scale up and start expecting more features and better performance. > > Ah, jut noticed nfgd has come back, with a new version. Check this out: > .... > .... > Bah, it seems worse than before. > .... Hardly likely. Changes from 2.0.4 to 2.0.7 where almost exclusively about the server pool, which doesn't use any kind of double-linked list structure. A google search on this glibc thing shows that there are indications this may be related to your binutils toolchain. Are you running special versions of glibc and friends? I can't reproduce this. -- ________________________________________________________________ Paul Stevens mailto:[EMAIL PROTECTED] NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED] The Netherlands________________________________http://www.nfg.nl
