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(at)sourceview(dot)com> wrote:
>> > > Lars Kneschke wrote:
>>> > >> Justin McAleer <justin(at)fehuq(dot)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(at)dbmail(dot)org
> > https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >

_______________________________________________
DBmail mailing list
DBmail(at)dbmail(dot)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(at)fehuq(dot)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(at)postgresql(dot)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