 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
9 messages in ru.sysoev.nginxRe: HTTP GEO Module and Memcached Mod...| From | Sent On | Attachments |
|---|---|---|
| Liang Jin | Apr 28, 2007 9:45 am | |
| Evan Miller | Apr 28, 2007 10:23 am | |
| Igor Sysoev | Apr 28, 2007 11:42 am | |
| Liang Jin | Apr 30, 2007 2:14 pm | |
| Evan Miller | Apr 30, 2007 10:45 pm | |
| Liang Jin | May 1, 2007 11:41 am | |
| Evan Miller | May 1, 2007 10:00 pm | |
| Evan Miller | May 5, 2007 12:20 am | |
| Liang Jin | May 5, 2007 2:47 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: HTTP GEO Module and Memcached Module question | Actions... |
|---|---|---|
| From: | Liang Jin (mywe...@public.gmane.org) | |
| Date: | May 1, 2007 11:41:16 am | |
| List: | ru.sysoev.nginx | |
On 4/30/07, Evan Miller <emmiller+gman...@public.gmane.org>
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