Re: Performance figures from DbMail list - Mailing list pgsql-general
From | Matthew T. O'Connor |
---|---|
Subject | Re: Performance figures from DbMail list |
Date | |
Msg-id | 4579B054.9030208@tocr.com Whole thread Raw |
In response to | Performance figures from DbMail list (David Goodenough <david.goodenough@btconnect.com>) |
List | pgsql-general |
Quick follow up on this, the guy who ran this test retested with a much newer version of MySQL and sent this message to the DBMail mailing list today. Ok, I just did the test on mysql 5.0.27. It took 73 seconds to deliver the 1000 messages. So, it's a good bit faster than 4.1.20's 95 seconds, but still pales in comparison to postgres' 9 seconds. Mysql was still peaking both cpu cores during delivery. On Thu, 07 Dec 2006 11:23:58 -0800 Michael Dean <mdean@sourceview.com> wrote: >> > > Lars Kneschke wrote: >>> > >> Justin McAleer <justin@fehuq.com> schrieb: > > I think a test of 5.0 and 8.2 would be great! Recent > > benchmarks of the > > two show pg really blows the socks off mysql, so a > > confirmation of that in the email segmnent would be > > terrific!!! > > Michael > > _______________________________________________ > > DBmail mailing list > > DBmail@dbmail.org > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > _______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail David Goodenough wrote: > The following appeared this afternoon on the DbMail list. As someone > replied the MySql used is old, and the newer one is faster, but then > 8.2 is faster than the older Postgresql versions. > > This was posted by:- "Justin McAleer" <justin@fehuq.com> > > I figured I would go ahead and toss this out for anybody > that may be interested, since I was so shocked by the > results. I have two servers set up for testing, one running > postfix/dbmail and one running the database servers. The > database machine is a dual core AMD (4400+ I believe) with > 4 gigs of memory, with the database files living on a fiber > connected Apple SAN (XRaid). I have dbmail compiled with > mysql and pgsql, so all I need to do to switch between the > two is change the driver in the conf file and restart. I'm > using dbmail-lmtpd running on a unix socket. Finally, I > have the postfix delivery concurrency set to 5. > > For mysql, I'm using a 4GB InnoDB sample config that comes > in the CentOS rpm (increased the buffer pool to 2.5 gigs > though). Version is 4.1.20. > > For postgres, I'm using the default variables except for > increasing the shared buffers to 256MB, setting effective > cache size to 3 GB, and random page cost to 2. Version is > 8.1.4. > > I've sent a good amount of real mail to each setup as well, > but for quantifiable results I have a perl script that > sends gibberish of a configurable size (3kb here) to a > single recipient. Since we're inserting into a DB, the > recipient of the messages should have no bearing on > delivery performance, barring postfix concurrency. > > For the test, I sent one batch of mail through so postfix > would already have a full lmtp connection pool when I began > the real test. I had 10 perl processes each sending 100 > messages as fast as postfix would accept them, for a total > of 1000 3KB messages. Results... > > Mysql: 95 seconds to deliver all 1000 messages. Both cores > on the DB server were effectively peaked during delivery. > > Postgres: 10 seconds to deliver all 1000 messages. DBMail > was really close to being able to deliver as fast as > postfix could queue to local disk (within a second or two > for 1000th message). The cores on the DB server looked to > average around 45%/30% usage during delivery. > > The CPU usage is just based on watching top output, so keep > that in mind... however with such a huge variance, even > eyeballing it I'm confident in reporting it. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- Matthew T. O'Connor V.P. Operations Terrie O'Connor Realtors 201-934-4900
Attachment
pgsql-general by date: