Just another data point.
I downloaded a snapshot yesterday - Changelogs dated Feb 20 17:02
It's significantly slower than "7.0.3 with fsync off" for one of my webapps.
7.0.3 with fsync off gets me about 55 hits per sec max (however it's
interesting that the speed keeps dropping with continued tests).
( PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66)
For 7.1b4 snapshot I get about 23 hits per second (drops gradually too).
I'm using Pg::DBD compiled using the 7.1 libraries for both tests.
(PostgreSQL 7.1beta4 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66)
For a simple "select only" webapp I'm getting 112 hits per sec for 7.0.3.
and 109 hits a sec for the 7.1 beta4 snapshot. These results remain quite
stable over many repeated tests.
The first webapp does a rollback, begin, select, update, commit, begin, a
bunch of selects in sequence and rollback.
So my guess is that the 7.1 updates (with default fsync) are significantly
slower than 7.0.3 fsync=off now.
But it's interesting that the updates slow things down significantly. Going
from 50 to 30 hits per second after a few thousand hits for 7.0.3, and 23
to 17 after about a thousand hits for 7.1beta4.
For postgresql 7.0.3 to speed things back up from 30 to 60 hits per sec I
had to do:
lylyeoh=# delete from session;
DELETE 1
lylyeoh=# vacuum; vacuum analyze;
VACUUM
NOTICE: RegisterSharedInvalid: SI buffer overflow
NOTICE: InvalidateSharedInvalid: cache state reset
VACUUM
(Not sure why the above happened, but I repeated the vacuum again for good
measure)
lylyeoh=# vacuum; vacuum analyze;
VACUUM
VACUUM
Then I ran the apachebench again (after visiting the webpage once to create
the session).
Note that even with only one row in the session table it kept getting
slower and slower as it kept getting updated, even when I kept trying to
vacuum and vacuum analyze it. I had to delete the row and vacuum only then
was there a difference.
I didn't try this on 7.1beta4.
Cheerio,
Link.
