On Fri, 4 Jul 2008, Michael Haardt wrote: > > There are two very different problems in Exim. One is basic queue > operations and the other is handling large queues. Don't confuse them. > > The first is not easy to change, and looking at other MTAs is not going > to help much if you want to squeeze out the most. Once Usenet had > the same problem, and the best idea ever to explore new ways of storing > messages was an storage API. Exim not only lacks that, it even lacks the > documentation which operations are required on queue entries.
Exim has part of a queue API, in the spool_in.c and spool_out.c files. However there are other places in the code that know about the queue layout so, as you say, it would need some refactoring to clean this up. > The second is way easier, if all you ask for is running a queue with > e.g. 100,000 entries. Right now, Exim requires a very nonlinear effort > for large queues, because each queue runner scans the entire queue, or > at least a part of it, and conflicts with other queue runners. Using a > single queue scan and forking deliveries off that is easy and gives way > more performance. Unfortunately, you can't say how many deliveries will > run, as a single delivery may start yet more children, but in the real > world, it works well enough to forget the whole problem for a while. It's probably worth changing Exim to support multiple concurrent deliveries from a single queue runner. You have done this with an external program (link below) but it would make sense to have the functionality built-in. http://lists.exim.org/lurker/message/20050623.095927.833cd3e6.en.html Tony. -- <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://dotat.at/ ${sg{\N${sg{\ N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\ \N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}} -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
