On 7 January 2016 at 10:34, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 6 January 2016 at 08:14, Greg Stein <gstein_at_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
Received on 2016-01-15 13:59:00 CET