WordPress.org

Ready to get started?Download WordPress

Forums

WP Super Cache
No compressed pages served (6 posts)

  1. RavanH
    Member
    Posted 4 years ago #

    Hi,

    Even though I have Super Cache in ON mode and Super Cache Compression enabled (but no other settings checked), there are no Gzipped pages/posts served to either my browser (logged out) or services like http://www.whatsmyip.org/http_compression/ and http://ismyblogworking.com/

    I checked the /cache/ folder and all .gz page/post files are there and have the proper content. The shared server has zlib.output_compression installed but it is turned OFF for my domain. All .htaccess rules are in order - as far as I can tell - and according to my hosting providers helpdesk mod_mime, mod_headers and mod_expires are available and running.

    Response Headers in the above case for any normal page/post :

    Date: Thu, 24 Jun 2010 02:03:21 GMT
    Content-Type: text/html; charset=UTF-8
    Connection: keep-alive
    Server: Apache/Nginx/Varnish
    X-Powered-By: PHP/5.2.12
    Vary: Accept-Encoding,Cookie
    Cache-Control: max-age=300, must-revalidate
    WP-Cache: Served supercache file from PHP
    Content-Length: 50656
    
    200 OK

    If I set SuperCache to HALF-ON mode, the result is exactly the same in spite of that message stating compression is on by default in HALF-ON mode... But as soon as I set zlib.output_compression in my php.ini to On, I get these headers:

    Date: Thu, 24 Jun 2010 02:22:33 GMT
    Content-Type: text/html; charset=UTF-8
    Connection: keep-alive
    Server: Apache
    X-Powered-By: PHP/5.2.12
    X-Pingback: http://...mydomain.../xmlrpc.php
    Content-Encoding: gzip
    Vary: Accept-Encoding
    Content-Length: 12571
    
    200 OK

    And back to ON mode (and Super Cache Compression to Enabled) still with zlib compression to On I get:

    Date: Thu, 24 Jun 2010 02:33:16 GMT
    Content-Type: text/html; charset=UTF-8
    Server: Apache
    X-Powered-By: PHP/5.2.12
    Cache-Control: max-age=300, must-revalidate
    WP-Cache: Served supercache file from PHP
    Content-Encoding: gzip
    Vary: Accept-Encoding
    Content-Length: 12559
    
    200 OK

    This would indicate the .gz files still being ignored else I 'd get served double compressed files... right ?

    I'd really like to get Super Cache pre-compressed pages served instead of the zlib dynamically compressed ones... What could be interfering ?

    Thanks for any thoughts :)

    http://wordpress.org/extend/plugins/wp-super-cache/

  2. RavanH
    Member
    Posted 4 years ago #

    Oh, and I also tested with umask( 0022 ); above the WP_CACHE line in wp-config.php but that did not change anything...

  3. Donncha O Caoimh
    Member
    Plugin Author

    Posted 4 years ago #

    Sounds odd but you've got Apache/Nginx/Varnish serving your files so perhaps rules need to be added to Nginx?

  4. RavanH
    Member
    Posted 4 years ago #

    Hmmmm... I have no idea. It's a shared host so I have no kind of access like that (php.ini is as fars as it goes). I contacted Support and they tell me "Our HTTP Server is Apache. The Apache is handling .htaccess files" so I would guess that the Nginx issues with .htaccess rules handling (like nested If rules ?) would pose no problem here. But I am only guessing here.

    Would a link to a phpinfo help anything?

  5. schirpich
    Member
    Posted 4 years ago #

    Sounds like a problem in varnish. Have you checked to see that a .gz file is being produced to varnish. What does apache's log say in the access.log when you try to reproduce this with a fresh cache all around?

    But let me ask you this, if you are using Varnish, why are you using both nginx and apache? You could have Varnish caching and serving nearly all of your static content even though it's "originally" coming from Apache (or nginx if you choose to ditch apache).

    You could simply tell varnish to pass the first image request straight through, which will then cache it with varnish on that first request. Eliminating any further passes to your backend until the next purge. Which you are probably already doing, but you are just running an extra webserver for no real reason. Once you eliminate the either of the webserver's you'll save yourself some extra memory and cpu time.

    I think you could even manipulate the VCL to store the larger cached items like pictures, zips or whatever to a disk cache file. And a separate sub section to store everything else to malloc with varnish.

    bleh,,, I'm just getting ahead of myself here. My point is, either go through each step to make sure a .gz file is being passed along. The logs will tell you this straight up. But I would also suggest you cut either nginx or apache out completely. With Varnish there's no need for the both of them.

  6. RavanH
    Member
    Posted 4 years ago #

    thanks schirpich, for your elaborate answer. i fear i cannot provide you with any response (i am on shared hosting and i think support will not be answering such questions) other than follow your advise and try to find out more via the access log files. if i find anything meaningful there, i 'll come back :)

    thanks again!

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic