Our app is very heavy on the SQL. I believe the record for one page was over 350 individual queries, though this has since been trimed by 50%. Every page is at least 3, though: two to re-load the logged in user and one to record profiling (but this is an INSERT DELAYED). At the moment, it's some 300 PHP pages talking to a MySQL database.

When we started looking at performance, we quickly discovered that unnecessary queries were causing us the most loss. Refactoring code to do one query and then create objects from all the rows rather than do one query that gave all the ids, and then one per id gained substantial gains. Most pages are in the 2-5 second mark on our development hardware (which is generally not to the level of our customers).

That said, there are still pages which take a long time to load. Generally these are pages which simply have to work with a lot of data. Also we're finding scaling problems past about 100 users, depending on the hardware, so we plan to completely re-write the app with a very different architecture. One of the key things I think we'll do is persistent in-memory storage on the application server - database storage will of course still occur, but it will have a much lower profile in the application code. I want to write a database layer that manages the objects in memory, their storage in the database and replication between other servers.

Wade.