You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Raphaël <ra...@gmail.com> on 2015/12/22 15:59:23 UTC
[users@httpd] Re: mod_cache for FallbackResource?
Any takers?
>From another discussion level I wanted to see if cache disk could
compete with Varnish, eg:
- Apache + mod_cache_disk + mod_ssl
could be a better stack than
- Apache + Varnish + Pound.
So far, I'm under the impression that managing a reverse-caching proxy
with mod_cache is, if even realistically possible, by far more complex
and less powerful than Varnish.
That's pretty hard to believe since being an Apache module, mod_cache
theorically benefits from a better integration and higher "knowledge"
from the backend HTTPd.
As an example, caching dynamic resources having different query strings
is a non-issue using Varnish (or most other reverse-proxy caches).
What makes mod_cache so specific in this regard?
On Tue, Nov 10, 2015 at 10:58:28AM -0300, Raphaël wrote:
> Hi,
>
> using php/fcgi, I've a Content Management System whose entry-point is /index.php
> On the Apache-side it makes use of FallbackResource
>
> According to the documentation:
> > As a filter, mod_cache can be placed in front of content originating
> > from any handler, including flat files (served from a slow disk cached
> > on a fast disk), the output of a CGI script or dynamic content
> > generator, or content proxied from another server.
>
>
> I want to benefit from this fine grained control and configure it as:
>
> > <VirtualHost *:80>
> > ServerName website
> > DocumentRoot "/var/www/website"
> > <Directory "/var/www/website">
> > Require all granted
> > AllowOverride None
> > <FilesMatch \.php$>
> > SetHandler "proxy:unix:/var/run/php5-fpm-website.sock|fcgi://blah"
> > </FilesMatch>
> > FallbackResource /index.php
> > </Directory>
> >
> > <Proxy fcgi://blah max=5>
> > </Proxy>
> >
> > CacheHeader On
> > CacheDetailHeader On
> > CacheQuickHandler Off
> >
> > <Location "/cacheit">
> > CacheEnable disk
> > </Location>
> >
> > <Location "/dontcache">
> > CacheDisable on
> > </Location>
> > </VirtualHost>
>
>
> A sample, not significant, index.php file inside /var/www/website:
> > <?php
> > $uri = trim($_SERVER['REQUEST_URI'], '/');
> > if ($uri == 'cacheit') header('Cache-Control: max-age=30');
> > elseif ($uri == 'dontcache') header('Cache-Control: no-cache');
>
>
> There are multiple issues, whatever syntax/order variations is used, like
> > `CacheEnable disk /`
> at the VirtualHost level.
>
>
> But the first one being that the <Location> directive are *not* taken into
> account.
> A sample of mod_cache debug output, when a `GET /dontcache` is issued soon
> after `GET /cacheit` (and results in a cached output):
> > cache_storage.c(664): AH00698: cache: Key for entity /index.php?(null) is http://website:80/index.php?
> > mod_cache_disk.c(572): AH00709: Recalled cached URL info header http://website:80/index.php?
> > mod_cache_disk.c(885): AH00720: Recalled headers for URL http://website:80/index.php?
> > mod_cache.c(601): AH00761: Replacing CACHE with CACHE_OUT filter for /index.php
> > mod_cache.c(652): AH00763: cache: running CACHE_OUT filter
> > mod_cache.c(681): AH00764: cache: serving /index.php
>
> Indeed htcacheclean -A only shows one unique version of stored, keyed "index.php"
>
>
> I did some attempts using `CacheQuickHandler On` and was able to get
> distinct cache entries for /cacheit and /dontcache.
> That was good but it does not solve the issue of <Location> not being
> taken into account (and the CacheEnable flag not being respected):
>
> Eg:
> > <Location "/private">
> > CacheDisable on
> > </Location>
> is not respected (wild guess: because /private is not a "real" resource)
>
>
> Moreover I'd rather stick with a normal cache handler since I hope it'd would
> make possible to insert Header/RequestHeader and I also expect to
> use things like:
> > SetEnvIfNoCase Cookie admin_cookie no-cache
> that the CacheQuickHandler would not treat.
>
>
> Question:
> Is there any way to make CacheEnable work on a granular <Location> basis
> when a FallbackResource is used and that the <Location> parameter is the
> original un-rewritten URL?
>
>
> Thank you!
--
GPG id: 0xF41572CEBD4218F4
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: mod_cache for FallbackResource?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Dec 22, 2015 at 11:03 AM, Eric Covener <co...@gmail.com> wrote:
>> As an example, caching dynamic resources having different query strings
>> is a non-issue using Varnish (or most other reverse-proxy caches).
>> What makes mod_cache so specific in this regard?
I see, this is specifically for FallBackResource. FallBackResources's
argument is a URL, not a path -- and that URL doesn't have a query
string. It makes sense that this doesn't work outside of the default
CacheQuickHandler ON (which would only see the original URL). Does it
also fail there?
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Re: mod_cache for FallbackResource?
Posted by Eric Covener <co...@gmail.com>.
On Tue, Dec 22, 2015 at 9:59 AM, Raphaël <ra...@gmail.com> wrote:
> Any takers?
>
> From another discussion level I wanted to see if cache disk could
> compete with Varnish, eg:
> - Apache + mod_cache_disk + mod_ssl
> could be a better stack than
> - Apache + Varnish + Pound.
>
> So far, I'm under the impression that managing a reverse-caching proxy
> with mod_cache is, if even realistically possible, by far more complex
> and less powerful than Varnish.
"...If even realistically possible"? Hard to take anything else seriously.
> That's pretty hard to believe since being an Apache module, mod_cache
> theorically benefits from a better integration and higher "knowledge"
> from the backend HTTPd.
It's a mixed bag.
> As an example, caching dynamic resources having different query strings
> is a non-issue using Varnish (or most other reverse-proxy caches).
> What makes mod_cache so specific in this regard?
Should be a non-issue in httpd, the query string is part of the cache
key. Is there
something wrong here when you don't put CacheEnable in <Location> or
is that tainting
all the other stuff?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org