On 6 January 2016 at 08:14, Greg Stein <gst...@gmail.com> wrote: > Personally, I'd be more interested in the effects on the network and its > caching ability. Do we really need to save CPU/IO on the server? Today's > servers seem more than capable, and are there really svn servers out in the > wild getting so crushed, that this is important? It seems that as long as > proxies/etc can properly cache the results, and (thus) avoid future touches > on the backend server, then we're good to go. > > If the patch doesn't affect the caching (which it sounds like "no"), then > just go with it. Sure, it is neat to look at ayscalls, but... why? I don't > understand the need to examine/profile. Educate me? >
The patch should not affect HTTP caching for two reasons: 1. Browsers and proxies supports ETag and use it instead of Last-Modified header. 2. ETag and Last-Modified headers are used only for cache re-validation when max-age is expired. But Subversion sets max-age=1 week for resources with specific revision in URL (http://server/!svn/rvr/1/path). max-age=0 is only used for public URLs without revision, i.e. http://server/path) As far I know proxy usage are limited to public servers with anonymous access, since caching of HTTP responses with Authorization is prohibited by RFC. Anyway I agree that trading bandwidth usage to save some CPU/IO on the server doesn't make sense, but Last-Modified case is the different: Subversion server wasting 10%+ of server resources to produce unused header. I don't have access to svn.apache.org server performance stats, but I suppose it's pretty busy server and Infra team would welcome any Subversion server performance improvements. -- Ivan Zhakov
