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.
--
Ivan Zhakov
Received on 2016-01-07 08:34:48 CET