HTTP GEO Module and Memcached Module question

[Liang Jin]

On 4/30/07, Evan Miller <emmiller+gmane at gmail.com> wrote:
>
> 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).

Hi, Evan. Are you indicating that the upstream module can be used
along with the memcached module to define a cluster of memcached
servers? And also use weight for different upstream servers? This
sounds good.

However, ip_hash operation seems a bit unclear. How are the requests
distributed among upstream servers? The algorithm should be known to
the backend script, so that the backend can make the corresponding
cache available on the same memcached server. Otherwise, the backend
would have to make the cache available on all the clustered memcached
servers in order to make the frontend nginx fetch the cached contents
in the first try.

Also, I am wondering about customizing the hash table. Is there anyway
to manually set a MD5 algorithm based on the request URL?

Another problem I am facing is the use of cookies. Backend caching is
done according to a MD5 hash of both the request URL and the available
cookies. However, nginx in the frontend could only fetch a cached key
in memcached using the request URL.

>
> 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.

Effectively, nginx would grab this information as the expiration
information for the cached contents, right?

I would think it is more flexible if nginx can get a key
(corresponding to the request URL, etc) from Memcached and assign the
content to a nginx variable. This way the variable can be set in the
backend to use Unix timestamp, or anything related to the cached
content. And additional handling of the variable can be used
(filtering, pattern matching, etc).

>
> Evan

-Liang