We're using an F5 for load balancing and SSL proxying. Behind it we're serving up java applications with Tomcat instances. These are fairly small applications - hundreds of concurrent users.
I'd like to compress some of the content, and I'm looking for advice on choosing to configure compression on the F5, or on the tomcat instances. Any big factors in the decision, or is it 6-of-one half-dozen of the other?
If you are doing Layer 7 load balancing (HTTP) then there is no real benefit in the app server compressing the content because the proxy will uncompress the content sending it to the client. This happens because the LB might support different version/option than what the client is requesting.
Example LB speaks HTTP/1.1 to app server but the client speaks HTTP/1.0. Second example LB supports compression therefore app server's response is compressed but the client doesn't support compression.
You should disable compression on the app servers and let the LB handle compression. You'll save the LB a couple of CPU cycles of uncompressing and recompressing the content.
Disclaimer. I have used other load balancers but not a F5.
The question really boils down to where you want the added overhead to handle the compression logic to run. If your app servers are beefy put it there, otherwise the F5 should be able to handle it. Regardless, this is something you will have to evaluate based on how much will get compressed and how much additional load that places on your systems.
BIG-IP does compression in hardware on most platforms (up to ~16Gbps). If your servers do it in software, you could save server CPU resources by doing compression there.
BIG-IP System Hardware Product Datasheet
http://www.f5.com/pdf/products/big-ip-platforms-datasheet.pdf
BIG-IP does not de-compress response content unless you've configured a feature which requires parsing of the response content (like HTTP response payload rewriting or ASM web app security response parsing).
Aaron