Caching, Compression, etc.
Simon’s got me thinking a lot about caching schemes lately. PeopleSoft’s applications has multiple levels of caching built in… a necessary thing for any enterprise application. It’s got file and memory based application/business component metadata level caching on the appserver, portal data (registry tree and content) memory based cache on the webserver (for different users and roles), and also browser level cache directives (expire http headers). All in all, a pretty complex scheme. On top of that, http compression can be applied to pages and/or it’s related assets (javascript, css, etc.)
All of this caching benefits the overall performance of the PeopleSoft apps, however, depending on the level of caching you decide to employ, you might easily see yourself buying more memory and CPU time. Most of the time, the benefits of caching far outweigh the overhead to no caching, but if you’re lacking CPU and memory (especially for an enterprise application), caching has a diminishing return.
Compression on the other hand, is a pretty small payload for a server and the client (depending on the cpu on the client). For bandwidth limited users, it’s a lifesaver. I use compression on this website since it’s hosted at my casa using my 128kb (upstream) DSL service. Without compression, you do notice a pretty dramatic difference on the speed of this site. However, I’m not certain that compression works in all cases. I’ve heard of problems using compression with browsers behind certain proxy servers — where the content either gets cut off or gets garbled. Internet Explorer 5.5 (and maybe 6 too) uses HTTP 1.0 by default when it’s behind a proxy server and leaves off the Accept-Encoding:gzip,deflate header… I’m not sure, but this may cause other problems in your application if you’re relying on HTTP 1.1. For this reason (among many others), I really hate Internet Explorer.