Date: Tue, 14 Oct 2008 22:18:31 +0200
From: Ivan Sergio Borgonovo <mail@webthatworks.it>
To: pgsql-general@postgresql.org
Subject: benchmark on D7 + PG 8.3 Re: Drupal and PostgreSQL -
	performance issues?
Message-ID: <20081014221831.0304144c@dawn.webthatworks.it>
In-Reply-To: <ABC43831-1DB5-4AF3-AAD5-E6A607B6AE34@hoegh.org>
References: <2434A118-CEFA-43A9-BA88-006EC1F80326@hoegh.org>
	<200810122214.53558.uwe@oss4u.com>
	<20081013090228.248a665f@dawn.webthatworks.it>
	<e7e0a2570810131945x1bbf10b8r67c0ac2a340b436f@mail.gmail.com>
	<20081014114011.0ebe495a@dawn.webthatworks.it>
	<dcc563d10810140556v399ce9ddq94e9c88da2b8a742@mail.gmail.com>
	<20081014184456.0b920620@dawn.webthatworks.it>
	<ABC43831-1DB5-4AF3-AAD5-E6A607B6AE34@hoegh.org>
Organization: http://www.webthatworks.it
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

forwarding here too cos I just got the copy sent to my personal
address and just much later the one from pg list... + adding some
more siege run.

On Tue, 14 Oct 2008 19:05:42 +0200
Mikkel H=C3=B8gh <mikkel@hoegh.org> wrote:

> Hmm, those are interesting numbers. Did you use a real, logged
> in, drupal session ID (anonymous users also get one, which still
> gives them cached pages).

> They are in the form of =20
> "SESS6df8919ff2bffc5de8bcf0ad65f9dc0f=3D59f68e60a120de47c2cb5c98b010ffff"
>=20
> Note how the thoughput stays in the 30-ish range from 100 to 400, =20
> although the response time climbs steeply. That might indicate
> that your Apache configuration is the main roadblock here, since
> that indicates that clients are waiting for a free Apache process
> to handle their request (I suppose you're using MPM_PREFORK)=E2=80=A6

right
ivan@wtw:~$ aptitude search apache2 | grep prefork
i A apache2-mpm-prefork             - Traditional model for Apache
HTTPD 2.1
But... well since Apache was not tuned... if I remember right it
comes with a default of 100 processes max.

I copied your siege line.

Apache config was nearly untouched with the exception of virtualhost
configs.
Everything was running on a nearly stock Debian etch.
thx for suggestions about tuning Apache...
Currently I'm just installing D7 on my notebook to see how it's
going.

The notebook is running Lenny... that comes with pg 8.3.

I really hope D7 is going in the right direction for DB support.
I really would like to help there but I'm overwhelmed by a
multi-months, thousands lines of code drupal/postgresql project.

OK these were run on:
Core(TM)2 CPU         T7200  @ 2.00GHz
2Gb RAM
notebook so no raid etc... actually a very slow HD.
Default debian lenny install of pg and apache NO tuning at all.
vserver kernel but not run in a vserver.
So pg is 8.3 stock debian install + minor tweak to pg_hba just to
setup all the stuff.
D7 with most modules on and basic cache systems on.

-c20
Transactions:                   1446 hits
Availability:                 100.00 %
Elapsed time:                  30.30 secs
Data transferred:               2.87 MB
Response time:                  0.42 secs
Transaction rate:              47.72 trans/sec
Throughput:                     0.09 MB/sec
Concurrency:                   19.87
Successful transactions:        1446
Failed transactions:               0
Longest transaction:            0.60
Shortest transaction:           0.09

-c100
Transactions:                   1396 hits
Availability:                 100.00 %
Elapsed time:                  30.13 secs
Data transferred:               2.77 MB
Response time:                  2.08 secs
Transaction rate:              46.33 trans/sec
Throughput:                     0.09 MB/sec
Concurrency:                   96.46
Successful transactions:        1396
Failed transactions:               0
Longest transaction:            2.67
Shortest transaction:           0.09

Pretty impressive improvement.
Hard to say if the improvement was due to D7 update or PG 8.3 update.
If I've to chse I'd say the improvement comes from drupal new
caching system.
I'll try to find some spare time and do some more extensive
benchmark.

It would be interesting to see which are the slowest queries.


--=20
Ivan Sergio Borgonovo
http://www.webthatworks.it