On 7 January 2016 at 10:34, Ivan Zhakov <i...@visualsvn.com> wrote: > 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. > Committed in r1724790.
-- Ivan Zhakov
