Hi, > Split the TEXT/BLOB data out of the primary table into tables of their > own indexed to the primary table by it's key column. This is part of what I was planning to do, there are a lot of stuff I am planning to split out into their own tables with reference key. The problem is I'm unsure whether the added overheads of joins would negate the IO benefits hence trying to figure out more about how Centos/Linux does the caching. > Think about distributing the parts to different boxes as necessary. > You can start with the DBMS which is the logical candidate. Eventually I figured that would probably have to be done but I don't know enough at this point. So I'm taking the approach of optimizing stage by stage starting with things I'm more familiar with and less likely to muck up totally, i.e.from the app/script side first. Then after getting more familiar with the setup, experiment with the hardware based solutions. > On the DBMS backend, give it plenty of memory, good storage for the > workload and good networking. Again problem is old server so memory is maxed, drives controller is probably not helping. > On the Apache/PHP side, look for a good DBMS inter-connect and some > PHP caching module and of course enough CPU for the PHP code and > network for Apache+DBMS inter-connect. > > If you wanted to split it up even more you could look into some sort > of PHP distributed cache/processing system and have PHP processed > behind Apache. Thanks for the heads up, I didn't realize it was possible to separate the PHP processing from Apache itself. However, for the time being, I'm probably still limited to a single server situation so will keep this in mind for future.