You should be using Squid to cache before you even hit the webservers. If there’s a cache miss there, you should hit Apache2/Lighttpd. If you have to do any dynamic PHP, then you should hit the APC cache first. If that is a miss and you have to generate dynamic page using PHP, then hopefully MySQL Query Cache is also being used. Lastly, if all else fails, MySQL will actually have to do a disk read.

The point is that there should be a heirarchy of caches used.

The UI layer processes user inputs into a usable form and outputs. It does templating and a few basic UI related tasks and that’s pretty much it. The UI component passes requests to an application logic component that does all of the real work. In some cases this component will call other components such as our enterprise back-end system, a remote system such as UPS, or a database - again always communicating in XML-RPC.

The code is kept clean and uncomplex by only using one method to interface between different systems. Systems that don’t speak XML-RPC, such as our enterprise system, are wrapped so that they do. It also makes it very easy to integrate these components into other applications regardless to what language you’re programming them in and of course you have the option to write different components in different languages if you need to. By breaking code into components each component can stay very clean, short, and to the point.

The work required to encode and decode XML-RPC requests is minimal and the different components can be on the same network or server. Your http connections can be reused so that there is no need to open them again for each request. If load gets high you can load balance multiple copies of individual components across multiple machines easily. It’s not bad for security too as you can firewall off back-end systems and databases so that the only possible access to them is through your exposed XML-RPC interface.