memcached HTTP 304 patch
bisente at bisente.com
Mon Nov 16 22:52:19 MSK 2009
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.
Vicente Aguilar <bisente at bisente.com> | http://www.bisente.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 895 bytes
Desc: not available
More information about the nginx