0

I use Redmine with Passenger and Nginx. I'm just wondering if there are any reasons to use gzip on option?

As I understand the CPU usage will be increased if I set this option on, but the users with slow internet connection get the pages faster.

But may be there are any recommendation or testes which help me to make the right decision.

0

3 Answers 3

3

The good question should sound like: "Is there any reasons to NOT use ngx_http_gzip_module". No, there isn't.

gzip_comp_level 1; gives a rather good compression ratio on text while CPU utilization stays low. So, even users with a fast Internet connection in terms of last mile will get the pages faster.

Google recommends to Use compression to make the web faster.

2

Using compression, your CPU usage will be higher, but your bandwidth utilization will be lower. If you're paying for bandwidth by the gigabyte (and many of us do) then this will benefit you as well.

@ChrisS makes good recommendations, but I'll expand on them a bit:

  • Static content that is already highly compressed, such as audio and video files, doesn't really benefit from gzip encoding, so there's no reason to waste your CPU trying to compress them again.
  • Static text-based content such as CSS and JavaScript files can be easily compressed, and nginx can handle this easily. Use gzip on for these content types.
  • Dynamically generated content should be gzip compressed by the web application instead of nginx, as it has a much better idea of whether the content should be compressed or not.
1
  • Actually nginx has builtin facilities to do smart decision regarding compression. You don't need to re-implement all that logic on the application level.
    – VBart
    Jul 20, 2012 at 18:12
-2

For:

  • dynamic content gzip off
  • static content that's:
    • easily compressed (html, css, js, xml) gzip on
    • not easily compressed (graphics, audio, video) gzip off.
6
  • 1
    Strange answer. Dynamic compression gzip on exists especially for dynamic content. For static there's gzip_static on in nginx.
    – VBart
    Jul 20, 2012 at 15:14
  • I'm not actually very familiar with nginx, this answer just applies to HTTPd compression in general.
    – Chris S
    Jul 20, 2012 at 17:04
  • And, as you wrote, dynamic content should not use compression? Why? Even this page is compressed.
    – VBart
    Jul 20, 2012 at 17:21
  • It's a generic statement, so take it with a grain of salt. The web server doesn't know the makeup of the dynamic content, so it wouldn't know if it should be compressible or not. Also, the web server would have to compress every single page, which chews up more CPU resources than you'd think. This site isn't actually dynamically generated, each page is intelligently cached instead. It's a fine line, but there are real distinctions when the cached copy can be cached compressed, thus eliminating the necessity of compressing the page every time it's delivered.
    – Chris S
    Jul 20, 2012 at 18:59
  • But you can tell the web server what should be compressed and what not by configuration, and it's easier than implement such logic in application. I also know that in future versions of nginx its cache will be able to compress stored data on the fly, and re-compress with better ratio in background.
    – VBart
    Jul 20, 2012 at 19:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.