From 7b1ac55f50bd580a8a9c6e9bfa8b178f1ab6f443 Mon Sep 17 00:00:00 2001 From: "Andrey A.I. Sitnik" Date: Fri, 23 Dec 2011 21:29:49 +0700 Subject: Gzip files on page caching MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: José Valim --- railties/guides/source/caching_with_rails.textile | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'railties/guides') diff --git a/railties/guides/source/caching_with_rails.textile b/railties/guides/source/caching_with_rails.textile index ec9bfd4d40..0bf9ca8887 100644 --- a/railties/guides/source/caching_with_rails.textile +++ b/railties/guides/source/caching_with_rails.textile @@ -64,6 +64,28 @@ end If you want a more complicated expiration scheme, you can use cache sweepers to expire cached objects when things change. This is covered in the section on Sweepers. +By default, page caching automatically gzips file (for example, to +products.html.gz+ if user requests +/products+) to reduce size of transmitted data (web servers are typically configured to use a moderate compression ratio as a compromise, but since precompilation happens once, compression ration is maximum). + +Nginx is able to serve compressed content directly from disk by enabling +gzip_static+: + + +location / { + gzip_static on; # to serve pre-gzipped version +} + + +You can disable gzipping by setting +:gzip+ option to false (for example, if action returns image): + + + caches_page :image, :gzip => false + + +Or, you can set custom gzip compression level (level names are taken from +Zlib+ constants): + + + caches_page :image, :gzip => :best_speed + + NOTE: Page caching ignores all parameters. For example +/products?page=1+ will be written out to the filesystem as +products.html+ with no reference to the +page+ parameter. Thus, if someone requests +/products?page=2+ later, they will get the cached first page. A workaround for this limitation is to include the parameters in the page's path, e.g. +/productions/page/1+. INFO: Page caching runs in an after filter. Thus, invalid requests won't generate spurious cache entries as long as you halt them. Typically, a redirection in some before filter that checks request preconditions does the job. -- cgit v1.2.3