[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Last-Modified HTTP header in GET responses

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Thu, 7 Jan 2016 10:34:24 +0300

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.