Welcome! Log In Create A New Profile

Advanced

Re: Details about HTTP Headers Caching module

Marcus Clyne
March 18, 2009 10:05AM
Hi Latesh,

Thanks for the information.

I have some further questions, mostly to give me a clearer idea of your
aims.

1) Are you only looking at caching redirection (i.e. 3xx) responses?
2) Are you looking to cache the responses in memory, on disk, or both?
3) When you say 'invalidate', do you mean purge (i.e. remove the cached
entry from the cache)?
4) How are you intending on purging the caches? Here are some possible
ways with pros/cons

- using ttl's (expiry times) for each cached object individually
Pros : provides the most granularity and will probably give the
smoothest load to backends
Cons : adds slight overhead to the request, and complexity in
writing it (if the caching part is done from scratch)

- purging all objects at once whenever you wanted
Pros : very simple to implement
Cons : might cause a temporary rush on the backends when objects are
purged

- purging a subsection of the objects on a regular basis (e.g. 1/32 of
the objects every 30 mins)
Pros : very simple to implement, much less of a rush on backends
after purges
Cons : limited granularity

5) How many objects are we looking at caching roughly? thousands,
millions, tens/hundreds of millions?

6) How many worker processes do you/will you use on the Nginx
installation (if you use more than 1, then this adds complexity to the
caching process, and makes memory caching a pain - to the extent that
you might as well use memcached for it).

7) Are you definitely looking at having an internal cache, or would you
be happy with using memcached? One idea I thought of is to check for
cached pages memcached first for a cached header, then serving from the
backend if no header-only object is found. A header-only response would
then put the object in memcached.
Pros : you could put objects/control the cache separately to the
Nginx installation, perhaps saving some overhead
Cons : for non-header-only objects, there would be the slight extra
overhead of checking memcached on each request (which would obviously be
slower than using an in-memory cache)

8) What kind of load does your server get (average req/s etc)?


I will probably have a few more questions later, but the answers to the
above should give me a better idea of what you want, and give me a
better idea of a good way to implement your task.

Regards,

Marcus.



Latesh Galia wrote:
> Here are some details about the module that we want to sponsor
> development for:
>
> 1. We want to use nginx as a reverse proxy for a Domain Forwarding
> Service
> 2. This would require nginx to cache responses that contain only
> headers and no body (301 HTTP responses)
> 3. We also need a way to invalidate caches. This should ideally be a
> command line tool.
>
> Regards,
>
> Latesh Galia
> Software Engineer,
> Directi
>
> http://www.directi.com
>
>
>
>
>
Subject Author Posted

HTTP Headers caching module development

Latesh Galia March 18, 2009 06:14AM

Details about HTTP Headers Caching module

Latesh Galia March 18, 2009 09:22AM

Re: Details about HTTP Headers Caching module

Marcus Clyne March 18, 2009 10:05AM

Re: Details about HTTP Headers Caching module

Marcus Clyne March 18, 2009 10:25AM

Re: HTTP Headers caching module development

Manlio Perillo March 21, 2009 07:51PM

Re: HTTP Headers caching module development

pf shineyear March 24, 2009 03:37AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 313
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready