As a matter a fact, I'm not interested
in the number of requests, but in the size of the request. I'd like the
cache to get the header to check if the cached resource is stale based
on the last-modified header.
Maybe by combining this strategy with
an expiration time of some hours, might even improve performance, such
that the cache only checks for the last modified time of the resource every
hour or something.
RE: [users@httpd] Apache
reverse and caching proxy
How does this work for you: it depends on what you
want.
If you want certain URLs to be revalidated with every request, you should
follow Joshua's advice and make sure that those resources are served with
Cache-Control: must-revalidate. If the source server is an Apache and the
resources are static files, you can probably use mod_headers (Header set
or Header append) to achieve this. The downside of this strategy is that
it makes caching the resource on the reverse proxy more or less pointless.
If you can accept a certain delay between the time where the source is
updated and the update becomes effective for the client, playing with CacheDefaultExpires
may get you there. The RP cache will be revalidated every time the cache
entry becomes stale, and you can determine the interval using CacheDefaultExpires.
That will reduce the number of requests that need to be forwarded all the
way to the source.
BR
-ascs
________________________________
From: Wim.Van.Leuven@xxxxxx [mailto:Wim.Van.Leuven@xxxxxx]
Sent: Thursday, January 12, 2006 3:27 PM
To: users@xxxxxxxxxxxxxxxx
Subject: RE: [users@httpd] Apache reverse and caching proxy
Hello Axel-Stéphane,
If I can follow what you are trying to tell me, I should add the "expiresactive
on" directive on the source server instead of the caching server?
12/01/2006 15:12
Please respond to
users@xxxxxxxxxxxxxxxx
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
" from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
