HTTP GEO Module and Memcached Module question

Evan Miller emmiller+gmane at
Tue May 1 09:46:17 MSD 2007

Liang Jin <mywebadmin at ...> writes:

> Thanks, Evan and Igor.
> HTTP_X_GEO worked fine in PHP now. And for memcached, the default_type
> text/html solved my problem. :)
> I noticed that Igor mentioned that you will expand the support for
> Memcached. I am curious about possible ideas on the improvement. I
> would suggest that maybe adding memcached cluster support would be
> great. For example, the requests can be distributed to several backend
> servers with memcached and the load would be distributed among them
> based on a certain request hash table. If one backend server went
> down, nginx could go on and try another one instead, probably based on
> a timeout value? Anyway, I am not that familiar with Memcached yet, so
> I am hoping someone would come out with some better suggestions,
> maybe. If this has been discussed before on the maillist, please bear
> with a newcomer here.

The only missing piece is directing traffic based on a hash of the URI.
Currently it's only possible to direct a request in a round-robin fashion, or
based on a hash of the IP address (with the "ip_hash" directive, see

The Memcached module already supports the failover mechanism you describe; you
can adjust the "memcached_next_upstream", "memcached_send_timeout", and
"memcached_read_timeout" to send a request to the next memcached on the list if
a request fails. See

The improvement I would like to see is storing a last-modified time in the
stored item's flag. Although the docs say the flag only stores 16 bits, it
actually has room for 32 bits:

That size is perfect for a Unix timestamp. This would let you return a 304 Not
Modified response from items in the memcache.


> Thanks.
> -Liang

More information about the nginx mailing list