On Thu, 2009-07-23 at 11:24 +0200, Thomas Gelf wrote: > Clunk Werclick wrote: > > On Thu, 2009-07-23 at 13:50 +1000, Barney Desmond wrote: > >> You need to ask yourself if this is a real problem, or something > >> you're just imagining. Mysql generally works fine, 50,000 messages a > >> day at 12 queries each, equates to several queries per second. This is > >> an "easy" load. > > That is a comfort to know. My main concern was this hammering was not > > optimal, but it is welcome to make as many queries as it likes if it > > does not crash the database server. Perhaps Postgresql would be a bit > > more manly ? but slower ? > > You'll probably not note a difference. I guess MySQL will allow you to > connnect() faster if using a local socket. However you should always use > proxy_read_maps - so connect()-times are not so relevant. > > I gave a quick look at the server statistics of our MySQL instance > providing Postix and Amavis config (not used as Amavis storage etc, its > only purpose is providing "configuration"): DB uptime 250 days with an > average of 300 queries per second (our reports are showing peeks of > slightly more than 6 million delivery attempts a day). > That is very reassuring Thomas, thank you.
Now I don't know if I should stay with SQL or drop to maps ? It is easier to configure with SQL from a web based front end - but to get SQL to dump to flat files and Postmap is also only a few Perl lines. What is a fool to do ? :-# > We are using multiple servers, but that's mostly as of disaster recovery > and failover reasons - you could handle similar traffic also on a single > host (using recent server hardware). > > A certain percentage of queries could of course be avoided if Postfix > where optimized for DB usage. As we know it isn't - this design choice > however keeps it flexible and simple. > > Best regards, > Thomas Gelf -- ----------------------------------------------------------- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.