Re: Performance figures from DbMail list

This link adds to the joy...

http://forums.mysql.com/read.php?25,93181,93181

So the most popular free "database" in the world is a lousy performing
product that accepts 'gabba gabba hey' as a valid timestamp. Someone
please, give me a reason not to get cynical...


> -----Original Message-----
> From: Matthew T. O'Connor [mailto:matthew@tocr.com]
> Sent: den 8 december 2006 19:35
> To: David Goodenough
> Cc: pgsql-general@postgresql.org
> Subject: Re: Performance figures from DbMail list
>
> 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