Lucas Rolff
October 30, 2016 05:50AM
What you could do (I basically asked the same question 1 week ago), is
that whenever you fastcgi_pass then enforce accept-encoding: gzip -
meaning you'll always request gzipped content from your backend - then
you can enable the gunzip directive by using "gunzip on;"

This means in case a client that does not support gzip compression,
nginx will uncompress the file on the fly - where rest of the requests
will be serving the file directly with a content-encoding: gzip - then
the supporting client will automatically do whatever it should.

First of all it saves you a bunch of storage and it should give you the
result you want. Serving (pre)compressed files to clients that support it.
--
Best Regards,
Lucas Rolff


seo010 wrote:
> Hi *B. R.*!
>
> Thanks a lot for the reply and information! The KEY however, does not
> contain different data from http_accept_encoding. When viewing the contents
> of the cache file it contains the exact same KEY for both MD5 hashes. Also,
> it does not matter what browser is used for the first request. For example,
> using a Google PageSpeed test at the first request will create the expected
> MD5 hash for the KEY, and a next request using Chrome will create a new hash
> for a file that contains the line "KEY: ..." that matches the KEY for the
> first MD5 hash.
>
> The third request also has a different KEY. I did not test any further, it
> may be that the KEY will change for every new client. The KEY does remain
> the same however for the same client. For example, the first request uses
> the MD5 hash as expected for the KEY (as generated by MD5) and it will keep
> using it in next requests.
>
> As gzip compression causes a huge overhead on servers with high traffic, I
> was wondering if Nginx would cache the gzip compressed result and if so, if
> there is a setting with a maximum cache size. It would however, cause a
> waste of cache space.
>
> In tests the overhead added 4 tot 10ms on a powerful server for every
> request compared with loading pre-compressed gzip HTML directly. It makes me
> wonder what will be the effect on servers with high traffic.
>
> As there appears to be no solution in Google, finding an answer may be
> helpful for a lot of websites and it will make Nginx the best option for
> full page cache.
>
> Best Regards,
> Jan Jaap
>
> Posted at Nginx Forum: https://forum.nginx.org/read.php?2,270604,270647#msg-270647
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

Pre-compressed (gzip) HTML using fastcgi_cache?

seo010 October 27, 2016 02:41PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

B.R. October 29, 2016 06:20PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

seo010 October 30, 2016 05:24AM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

Lucas Rolff October 30, 2016 05:50AM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

seo010 October 30, 2016 01:03PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

Lucas Rolff October 30, 2016 01:54PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

seo010 October 31, 2016 03:08PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

Lucas Rolff October 31, 2016 03:46PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

seo010 October 31, 2016 03:56PM

Re: Pre-compressed (gzip) HTML using fastcgi_cache?

seo010 October 31, 2016 03:59PM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 148
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready