On Tue, Nov 13, 2012 at 12:20 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> We at WANdisco had a discussion about serf in 1.8 today; I'd said I
> summarise to the list.
>
> One concern is the impact on server performance, particularly older
> servers, of serf as the only client. Issue
> http://subversion.tigris.org/issues/show_bug.cgi?id=3980 has some
> figures. The CPU load has improved recently, serf is no longer such a
> CPU burden on the server. The bandwidth is still a concern because serf
> responses default to uncompressed data while neon responses default to
> svndiff compression. Using mod_deflate is the proposed solution and
> that does address the bandwidth but at the expense of CPU. Also there
> has been an important fix to mod_deflate that is not yet in Apache 2.2
> which may prevent some people enabling mod_deflate (although I did use
> 2.2 and mod_deflate in my tests).
>
Is that a fix that we can get in apache 2.2? Justin?
> A caching proxy is another solution to the server load. Caching using a
> proxy like squid does work but also has problems. When authn is in
> operation it appears that caching is either hard or not allowed, squid
> certainly doesn't cache. mod_cache might be better but is probably more
> complicated to setup and manage. Perhaps we need to document a
> recommended configuration?
I agree on the recommended configuration. I also propose to implement
such a configuration on svn.apache.org, we need some numbers on
behavior of the 1.8 client with the advised server setup.
> Another problem for proxy caching is that no released Subversion
> currently sends the Vary: header that is required for caching to work
> reliably. I can provoke this error by using squid and Subversion
> 1.6.19:
>
> $ svn up wc1 --config-option servers:global:http-proxy-host=::1 --config-option servers:global:http-proxy-port=3128
> Updating 'wc1':
> ../src/subversion/svn/update-cmd.c:168: (apr_err=200003)
> ../src/subversion/libsvn_client/update.c:639: (apr_err=200003)
> ../src/subversion/libsvn_client/update.c:579: (apr_err=200003)
> ../src/subversion/libsvn_client/update.c:440: (apr_err=200003)
> ../src/subversion/libsvn_wc/adm_crawler.c:858: (apr_err=200003)
> ../src/subversion/libsvn_ra_serf/update.c:2529: (apr_err=200003)
> ../src/subversion/libsvn_ra_serf/util.c:2057: (apr_err=200003)
> ../src/subversion/libsvn_ra_serf/util.c:2038: (apr_err=200003)
> ../src/subversion/libsvn_subr/stream.c:162: (apr_err=200003)
> ../src/subversion/libsvn_delta/svndiff.c:877: (apr_err=200003)
> ../src/subversion/libsvn_delta/text_delta.c:823: (apr_err=200003)
> svn: E200003: Delta source ended unexpectedly
>
> I wonder if serf could detect the SVN_ERR_INCOMPLETE_DATA error and
> check if Vary: header was received? It could then suggest a possible
> reason for the error? Perhaps it could even retry with a no-cache
> header? Or should we provide a way for users to cause serf to always
> send no-cache?
I haven't investigated in this issue yet, but maybe something like
this will avoid the wrong behavior: the 1.8 serf client can find out
if mod_dav_svn adds the Vary header correctly, and if not send
"Cache-Control: no-cache" and "Pragma: no-cache" headers for requests
where needed.
> I wonder if mod_headers could be used to add the missing
> Vary headers? I'm guessing that the absence of the Vary header would
> also prevent the use of mod_cache.
>
> Another concern is the increased server logging due to the large
> increase in the number of requests. A 1.8 server does better than older
> servers, about 50% fewer requests on checkout, but there is still a big
> increase over neon. No solution other than "it happens".
>
> The memory leak with older servers, issue
> http://subversion.tigris.org/issues/show_bug.cgi?id=4194 will be a big
> problem if it is not fixed. CMike has worked on this recently and I
> think the problem is understood but the solution is not yet known.
>
> Serf is much better than when 1.7 was branched but is it suitable as the
> only client in 1.8?
>
Personally, I'd keep neon as fallback for at least one release.
This specifically because serf supports not 100% all svn setups out
there. One thing I know of is smartcard support which serf doesn't
have and I won't be able to add in the near future (maybe others will
though). Also, there might well be a windows-kerberos triple trusted
domain .. setup somewhere where svn+neon works and svn+serf doesn't
work. These concern maybe only 1% of the users, but we should have a
plan to support them, and I think keeping neon in the build as the
easiest way to do that.
Lieven
Received on 2012-11-13 08:27:01 CET