Hi everyone
I’m new to the list, have looked for something like this but couldn’t
find it. Sorry if there’s a patch like this already.
I’m working on the server architecture for a new web portal. It’s going
to be Amazon-EC2 based and will have a nginx front end to several tomcat
back end servers. The nginx servers will proxy-cache some dynamic pages
(search results, internal web-services queries) and will also have a
static page cache based on memcached.
While starting to roll memcached into the solution I noticed that I
stoped receiving HTTP 304 responses, everything served off memcached
where 200. After digging a little bit on Google I found out it was the
expected behavior as memcached doesn’t store the timestamp
(last-modified) of the files. So I’ve given it a try and developed a
quick patch.
There are two parts to the patch:
-
a memcached patch that stores the current epoch on the flags field
when storing a new key-value pair. IMPORTANT: whatever flags the client
tries to set get lost, as the server overwrites them with the current
timestamp!!
-
a nginx patch to properly set the “last-modified” HTTP header
according to the memcached-stored flags (timestamp).
The patches have been tested with nginx 0.7.62 and memcached 1.2.2. I’ve
been testing it this morning at work and seems to work as expected, will
do more extensive tests tomorrow.
I’m quite puzzled at the simplicity of the patch, as I didn’t need to
code the logic to check if the cached page is more recent than the
client’s one and return 302 or 200. After successfully returning the
last-modified header from memcached, nginx seems to do the rest of the
job somewhere on its own! In fact the ims variable on the patch is never
used. I’m not familiar with nginx source code, today is the first day
I’ve looked into it, so maybe this was expected behavior. Could someone
more experienced on nginx internals confirm this?
If anyone gives this a try, please let me know your experiences.
Regards
On Tue, Nov 17, 2009 at 3:52 AM, Vicente A. [email protected]
wrote:
There are two parts to the patch:
- a memcached patch that stores the current epoch on the flags field when storing a new key-value pair. IMPORTANT: whatever flags the client tries to set get lost, as the server overwrites them with the current timestamp!!
Isn’t it better to tell ngx_memcached to set the flags field and avoid
patching the memcached server?
Cheers,
-agentzh
Hi
- a memcached patch that stores the current epoch on the flags
field when storing a new key-value pair. IMPORTANT: whatever
flags the client tries to set get lost, as the server overwrites them
with the current timestamp!!
Isn’t it better to tell ngx_memcached to set the flags field and avoid
patching the memcached server?
But nginx isn’t the one setting the values on memcached, that’s the app
running on tomcat. Anyway I guess we could take a look at the flags on
the first access to a key and if the field is uninitialized (0) set it
to the current timestamp. But that wouldn’t be the real modification
time of that page, but that of the second access to it (fist time
memcached misses and nginx passes control to tomcat who sets the value,
second time the page is served from memcached). Wouldn’t really make a
difference, I guess. It would work. Anyway I don’t like nginx setting
it, nginx is the one serving it, not producing it.
Another less intrusive option is not modifying memcached and having the
developers set the timestamp on the flags everytime they store something
on memcached (or patch the library they use to access it). Quite easy to
do, we could just overload the method they use to store stuff on
memcached and set the timestamp there. But right now I wanted something
automatic, something I could test without changing our app’s code.
Regards
On Tue, Nov 17, 2009 at 2:33 PM, Vicente A. [email protected]
wrote:
But nginx isn’t the one setting the values on memcached, that’s the app running on tomcat.
nod
Was assuming you were using ngx_memcached in your app to set values
too, because I had been thinking seriously about adding
set/add/replace/delete/cas/incr/decr/etc support to ngx_memcached
Sorry about that.
Thanks for making this clear
Cheers,
-agentzh