Caching headers
Geoffrey Sneddon
As Michael correctly pointed out earlier today, I had said that I
would write an email about caching. So, here goes:
At the moment we send, in the HTTP headers, "Cache-Control: no-store,
no-cache, must-revalidate, post-check=0, pre-check=0". This means on
every request we need to, through PHP, create the page over again.
While with a single user requesting a page this seems sensible enough
to make sure they don't miss out any new posts/comments, it doesn't
scale well. On high traffic sites, it is desirable to run something
like Apache's mod_cache which caches the output, and keeps it for as
long as the Cache-Control headers allow, or a predefined maximum,
whichever comes first. This has the advantage of, with it set to cache
for one minute, for example, each page only has to go through PHP/DB
once per minute, which can inevitably make a _large_ difference in
performance.
Now, the problem is how we avoid these cache control headers being
sent. We don't actually send these ourselves, but they are actually
sent by PHP's session extension upon calling session_start() (there
are config options, session.cache_limiter and session.cache_expire,
that alter what is sent). What we want to do is allow pages to be
cached for a certain time (maybe 30 minutes, maybe less?) for non-
authenticated users, and forbid caching for logged in users. As what
gets returned for certain URLs varies upon the Cookie sent, we need to
vary on the Cookie header. (We actually need this already, but because
caching is not allowed, this isn't ever a problem.) If we vary on the
Cookie header, we need all anon users to send the same Cookie header,
to which the obvious solution, I think, is to not send cookies to anon
users.
I couldn't, in the brief time I looked, manage to implement this. This
is going to be needed for us to really be usable on really high
traffic sites where caching is an absolute necessity (caching at an
Apache level can, in my testing, provide around a 300 times increase
in the number of requests served per second).
--
Geoffrey Sneddon
<http://gsnedders.com/>
Owen Winkler
>
> Now, the problem is how we avoid these cache control headers being
> sent. We don't actually send these ourselves, but they are actually
> sent by PHP's session extension upon calling session_start() (there
> are config options, session.cache_limiter and session.cache_expire,
> that alter what is sent). What we want to do is allow pages to be
> cached for a certain time (maybe 30 minutes, maybe less?) for non-
> authenticated users, and forbid caching for logged in users. As what
> gets returned for certain URLs varies upon the Cookie sent, we need to
> vary on the Cookie header. (We actually need this already, but because
> caching is not allowed, this isn't ever a problem.) If we vary on the
> Cookie header, we need all anon users to send the same Cookie header,
> to which the obvious solution, I think, is to not send cookies to anon
> users.
This will preclude the ability for anonymous users to be associated to
session data. Posted form results may eventually become (if they're not
already) inseparable from the necessity of a user to maintain a session.
That is, the form submission process would accept a POST request, set
the result of the form processing into the session, and then redirect to
a GET request of a resource that would display the form result from the
session in addition to its own content. If anonymous users don't have
sessions/cookies, then this is not possible.
Should a user not have a session (erg cookie) assigned until it must be?
Is this possible? Is it helpful for caching?
Owen
Geoffrey Sneddon
On 1 Jul 2009, at 22:39, Owen Winkler wrote:
> Geoffrey Sneddon wrote:
>>
>> Now, the problem is how we avoid these cache control headers being
>> sent. We don't actually send these ourselves, but they are actually
>> sent by PHP's session extension upon calling session_start() (there
>> are config options, session.cache_limiter and session.cache_expire,
>> that alter what is sent). What we want to do is allow pages to be
>> cached for a certain time (maybe 30 minutes, maybe less?) for non-
>> authenticated users, and forbid caching for logged in users. As what
>> gets returned for certain URLs varies upon the Cookie sent, we need
>> to
>> vary on the Cookie header. (We actually need this already, but
>> because
>> caching is not allowed, this isn't ever a problem.) If we vary on the
>> Cookie header, we need all anon users to send the same Cookie header,
>> to which the obvious solution, I think, is to not send cookies to
>> anon
>> users.
>
> This will preclude the ability for anonymous users to be associated to
> session data. Posted form results may eventually become (if they're
> not
> already) inseparable from the necessity of a user to maintain a
> session.
For some forms, this is already the case.
> Should a user not have a session (erg cookie) assigned until it must
> be?
IMHO yes (for reasons of cachability — this is what I meant to say in
my original post, and was the main part of what I tried to implement).
> Is this possible?
Theoretically this should be, but from my brief time trying to
implement this, it is not going to be easy to implement.
> Is it helpful for caching?
Yes, we just need to maximise cache validity (i.e., making a cache
file valid for as many users as possible, and not having submitted
forms will be the majority).