8

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?

Dan
  • 620
  • 5
  • 18

3 Answers3

6

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.

Sameer
  • 4,070
  • 2
  • 16
  • 11
  • Thank you for this answer! I also have TLS termination on a reverse proxy, and was thinking on where to GZIP the content. It did not occur to me that it makes no sense to do it on the application as the frontend cannot just proxy the gzipped data, it has to unzip it to send it to the user in TLS mode. TL;DR: only gzip data on the reverse proxy if you are doing Layer 7 load balancing. Thanks again! – IvanD Apr 10 '21 at 21:32
2

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.

Brent Pabst
  • 6,059
  • 2
  • 23
  • 36
-2

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

Aaron
  • 39
  • 4