HTTP GEO Module and Memcached Module question

[Evan Miller]

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
http://wiki.codemongers.com/NginxHttpUpstreamModule).

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 http://wiki.codemongers.com/NginxMemcachedModule.

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:

http://lists.danga.com/pipermail/memcached/2007-April/004071.html

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

Evan

> 
> Thanks.
> 
> -Liang
>