Michael Monnerie wrote: >> seems to be your questions should be addressed to your RDBMS first. > > It would surely be postgresql. But I cannot ask there if they don't run a > dbmail system ;-) So the best place to know this should be here. > >> anyway, I didn't see, technical, barriers for dbmail to handle your > workload, but never heard about any tests. > > And my current systems only run up to 100 e-mails/s, this new project is a > bit bigger than usual, so I don't have experience with it. I believe there > are some people here running big systems, maybe they can tell...
with 100/s, what is your testing setup? I mean I can setup a test for measuring pipe delivery (sucks), but I dont have a good lmtp client other than an mta. Simply doing 'cat lmtp-dump.txt|dbmail-lmtpd -n' doesnt work :-( - one of the things I'm working on in the libevent sprints. One bottleneck in delivery is that we treat message insertion as one single transaction. Also, the total number of queries used, will most likely leave room for improvement. But 1k/s seems pretty fast. I just did a small test. Inserting a small real message results in 64 queries. Of those 26 are inserts. And 26k inserts/s sounds to me like big-iron dbms. Is anyone running postgres with those loads, I wonder? And you want to provide large scale imap access while you do that? But long live partitioning. Dbmail could be modified to be able to use separate database instances for separate users or groups. As the injecting lmtp mta-frontends can more easily be configured to do as well. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
