On Tue, Oct 22, 2002 at 05:31:22AM +0300, Timo Sirainen wrote:
On Tue, 2002-10-22 at 04:24, Timo Sirainen wrote:
Just had a thought. Would it be feasible to _try_ to permanently assign users to one or few specific servers (via ip or maybe login proxy)? If those servers were down, it could fallback to any random one.
Yes, the Alteons we use can be configured quite flexibly. We can easily configure, e.g., two servers as 'primary' and two fallback servers, or do load-balancing based on the output of a script, or any number of things. We only use the general load-balancing (actually just active-connection-balancing) while keeping sessions on the same server (based on remote IP) but we could look into the more intricate methods. A single IMAP server with a backup is a good start though.
Dovecot could actually do that itself too, authenticate user and then either locally handle it or transfer it to another node based on some configuration.
You mean if you have a frontend with several backends, and the frontend proxies for the backends (with several frontends possible, for redundancy,) hmm, that might work. Diablo (the news server software) works like this, somewhat, too, and we also use it behind Alteon switches :)
I really like this idea, keeping indexes in local disk where they may be considered as fast non-permanent data and then reading the actual mail data via backed up NFS server. This gets me thinking of a lot more possible optimizations to reduce NFS I/O at the cost of more local.. :)
This again makes the indexer process possible and useful, since it would be accessing only local disks. It could also delete some of the older indexes if disk space is getting full.
Yes. Keeping things on local disk sounds good. As long as opening the same mailbox on another server doesn't break anything (or breaks 'cleanly', doesn't delete the wrong mails etc) we can definately live with much worse performance for those cases. My professional estimate is that they will be very, very rare ;P
But for the time being we're more concerned with the SORT extention :) I've read the spec, and besides the natural "ugh" at having to parse the subject that way, it seems doable... except that charset support for UTF-8, as well as US-ASCII, is mandatory. I don't know any libraries that convert to/from UTF-8 (though ASCII<->UTF-8 is obviously simple :) and though it's probably easy to roll your own for iso8859-1 I'm not sure if you had a solution in mind yet. Also, supporting the other character sets (like UW-IMAP does) is probably a lot trickier.
Other than the charset issues I could probably whip up a working SORT implementation given enough time... but it probably wouldn't be super-efficient, as quicksort is so much easier to start with than, say, a mergesort ;P
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!