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@xxxxxxxxxxxxxx> wrote:
>> > > Lars Kneschke wrote:
>>> > >> Justin McAleer <justin@xxxxxxxxx> 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@xxxxxxxxxx
> > https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
_______________________________________________
DBmail mailing list
DBmail@xxxxxxxxxx
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@xxxxxxxxx>
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@xxxxxxxxxxxxxx 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
begin:vcard
fn:Matthew O'Connor
n:O'Connor;Matthew
org:Terrie O'Connor Realtors
adr:;;75 E. Allendale Rd;Saddle River;NJ;07450;USA
email;internet:matthew@xxxxxxxx
title:V.P. Operations
tel;work:201-934-4900
x-mozilla-html:FALSE
url:http://www.tocr.com
version:2.1
end:vcard
