http://www.snell-pym.org.uk/archives/2007/01/24/http-caching/ Sarah and Alaric Snell-Pym living in interesting times Tue, 02 Dec 2008 14:33:45 +0000 http://wordpress.org/?v=2.5 http://www.snell-pym.org.uk/archives/2007/01/24/http-caching/#comment-24282 @ndy Thu, 25 Jan 2007 11:28:58 +0000 http://snell-pym.org.uk/archives/2007/01/24/http-caching/#comment-24282 <p>Hmmm... If you return a cookie then you automatically become non cacheable (sp?). This means that you can't use one in the backend to work out when the user last requested the page. It's also really hard to track it via source IP & timestamp logging. In the stoictv.com database I keep an mtime for each item in the DB but, without knowing when your user last visited, you can't accurately use it for very much. My initial hunch was that you needed to know the users "last seen ETAG" in order to get the most efficient use of server resources. Now, if you do know it then, if the spec permits, you could send the new page all in a single response when their ETag is old; that saves you a little network traffic. If you don't then you just end up with a maximum of two requests. However, like Ben implies, if you have a table consisting of ETag, object IDs and mtimes, you can compare those to the actual object mtimes and return the stored ETag if you have a match. With clever use of indexing and/or triggers you can make that a really cheap operation. If the client is happy then they will go away and you won't hear from them again. You could even store your own, pre-rendered version of the page in your ETag table. Then, if you get a "cache miss" you can fob the client off and you can be pretty sure that it'll be coming back quite soon so you can immediately start rendering the latest version of the page into your cache table. So, I guess, by having a "front end" that models their cache, you only have to render your pages once and then serve everything out of your cache table. The stoictv.com engine doesn't currently use the mtimes to do this but I might try it out soon...</p> Hmmm... If you return a cookie then you automatically become non cacheable (sp?). This means that you can't use one in the backend to work out when the user last requested the page. It's also really hard to track it via source IP & timestamp logging. In the stoictv.com database I keep an mtime for each item in the DB but, without knowing when your user last visited, you can't accurately use it for very much. My initial hunch was that you needed to know the users "last seen ETAG" in order to get the most efficient use of server resources. Now, if you do know it then, if the spec permits, you could send the new page all in a single response when their ETag is old; that saves you a little network traffic. If you don't then you just end up with a maximum of two requests. However, like Ben implies, if you have a table consisting of ETag, object IDs and mtimes, you can compare those to the actual object mtimes and return the stored ETag if you have a match. With clever use of indexing and/or triggers you can make that a really cheap operation. If the client is happy then they will go away and you won't hear from them again. You could even store your own, pre-rendered version of the page in your ETag table. Then, if you get a "cache miss" you can fob the client off and you can be pretty sure that it'll be coming back quite soon so you can immediately start rendering the latest version of the page into your cache table. So, I guess, by having a "front end" that models their cache, you only have to render your pages once and then serve everything out of your cache table. The stoictv.com engine doesn't currently use the mtimes to do this but I might try it out soon...

]]> http://www.snell-pym.org.uk/archives/2007/01/24/http-caching/#comment-24181 Ben Wed, 24 Jan 2007 12:21:07 +0000 http://snell-pym.org.uk/archives/2007/01/24/http-caching/#comment-24181 <p>Quick fix thingy... how about declaring that a script's output depends on the state of database tables x, y, and z. Add triggers to work out when the last changes were. Use for last modified and working out whether to rerun the script.</p> Quick fix thingy... how about declaring that a script's output depends on the state of database tables x, y, and z. Add triggers to work out when the last changes were. Use for last modified and working out whether to rerun the script.

]]>