I've recently moved a WordPress blog over to my DreamHost PS and after some problems with php-cgi spikes and 30 second lockups, I also started to use the nginx and FCGI that you can enable from the admin panel with Xcache, since I'm familiar with it from running it locally on my Mac too.
The site itself has great load times on nginx. I run the SuperCache plugin for WordPress, and almost all the content is served statically, so that's not a problem. My problem, however, is that the admin panel, which is dynamic PHP, regularly has pages take 10 seconds to load, despite Xcache's opcode caching. In fact, it seems slower than when it ran on the shared server.
I did some benchmarks with the Apache 'ab' benchmarking app and once I bumped the memory cache for Xcache up to 64 megs from the 16 that it used by default, the load times for an uncache front page almost trippled, so that's doing it's thing too.
The TTL for cached PHP pages is set to an hour, but if I visit the page for recent posts on the WordPress admin panel, it'll take 5-10 seconds the first time, 2-3 the next time if I reload right away and then when I come back after a few minutes, it taked 5-10 seconds again. It's as if something is causing whatever caching sped things up the second time around to become undone within minutes.
Using the admin panel graphs that Xcache offers, once I bumped the cache size up to 64 megs, it's got plenty of room to spare, so it doesn't look like it was forced to uncache pages quicker because it ran out of memory.
I'm stumped as to why admin panel pages are still slow. Is something telling Xcache to expire pages earlier, despite what my custom PHP.ini says? Again, the Xcache admin panel confirms my settings.
I'm now wondering if the bottleneck is MySQL. I'm still using the shared MySQL server, but have just put in to migrate over to a PS MySQL server too earlier today. I've just tried out the MySQL profiler plugin. The main page that I can replicate slowness on, the posts page, does a whopping 83 different SQL queries, compared to 15-40 on other pages.
Could it be that at some point the shared MySQL server queue up my new queries and gives someone else a new chance to execute queries for a while? The actual individual queries are pretty quick (fractions of a second), so if MySQL is a problem, it must be a problem of delays in between queries. Or the fact that a PS is now hitting the shared MySQL server, which might be on another part of the network could be a problem?
There's also a PHP profiler plugin, but that output has been less useful, since it just confirms, that the page as a whole too a long time to execute on the server, but not which parts of it took how long.
Anyone have experiences fine tuning a PS using this stack that might help out here?