> Each of the 256 requests was being processed by a php process. So, it
> could
> certainly be faster. But, the fact that we're seeing the db performance
> degrade would seem to indicate that our application is fast enough to
> punish
> the db. Isn't that true?
Not necessarily. Your DB still has lots of idle CPU, so perhaps it's your
client which is getting over the top. Or you have locking problems in your
DB.
Things to test :
- vmstat on the benchmark client
- iptraf on the network link
- monitor ping times between client and server during load test
Some time ago, I made a benchmark simulating a forum. Postgres was
saturating the gigabit ethernet between server and client...
If those PHP processes run inside Apache, I'd suggest switching to
lighttpd/fastcgi, which has higher performance, and uses a limited,
controllable set of PHP processes (and therefore DB connections), which in
turn uses much less memory.
PS : try those settings :
fsync = fdatasync
wal_buffers = 64MB
walwriter_delay = 2ms
synchronous commits @ 1 s delay
