0

Consider the following server setup on a network: network example

In this example, both of the proxy servers are Nginx servers.

If the aim is to reduce load time for the client, should compression be used by the Nginx servers (using the gzip directive) at point A, or point B, or both? Is there any theoretical way to determine this without simply testing it.

Edit: Is it worth considering that within the network there is very high throughput, but outside the nextwork (ie connection A) there is less guaranteed of speedy throughput.

1 Answer 1

0

Assuming that you're really talking a data pipeline, if you gzip sooner rather than later, the rest of the path just gets to move the more compact data around.

If you gzip at both places, the later point should see that the traffic is already compressed and not do it again.

But if you have compression turned on at both places, but they're not using the same compression, the latter point might not recognize the other algorithm, and so try to compress with the new algorithm. This usually costs more time, because compressed data is usually not as compressible as uncompressed data and the extra compression yields little if any benefit (and can make things worse.) Also, many clients aren't expecting doubly-compressed results, and may just undo the second layer of compression rather than both.

Also, if your frontend server is looking at the content provided by the content server and tweaking it, then it's going to need to decompress anything that the content server sends it compressed. There are compression algorithms for this sort of use case, like LZO compression. I have not really looked into these algorithms, as I mostly compress data at rest and data moving from across two or more timezones.

Just to be clear on that additional case: if the content provided by the content server is passed on to the client as distinct files from anything the frontend is providing, it probably doesn't matter to the frontend server if that data is already compressed. If, on the other hand, you're prepending a beginning of a webpage, and then adding after it the end of a web page, then having the stuff that goes between that beginning and that end separately compressed just doesn't work. I hadn't considered this case, because I assumed that you were asking about two cases that you had working code to handle, but couldn't figure out how to benchmark since you're at your site and the client isn't.

4
  • My only concern is that the Frontend adds more data being the webserver. However in this case the bulk of the data being moved is coming from the content server, so maybe it could be considered a negligible amount.
    – Stringers
    Feb 27, 2019 at 2:28
  • @Stringers depending on how the Frontend adds more data to the webserver, the update I just made may or may not affect your final result.
    – Ed Grimm
    Feb 27, 2019 at 2:57
  • Thank you for the additional clarifications. The frontend does not tweak the data being provided by the content at all. It simply uses an html iframe instance to render it, then adds some additional functionality over the top.
    – Stringers
    Feb 27, 2019 at 3:13
  • If you gzip at both places, the later point should see that the traffic is already compressed and not do it again. My experiments show that when one nginx proxies to another, and both has gzip on, the inner nginx for some reason doesn't compress the data. But when asked directly it does. A detailed report here.
    – x-yuri
    Feb 1, 2023 at 23:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .