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

Re: Status of ra_serf?

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 2 May 2012 12:45:20 -0400

On May 2, 2012 10:26 AM, "Johan Corveleyn" <jcorvel_at_gmail.com> wrote:
> Innocent bystander's question, before 1.8 starts to be cast in stone:
> what's the status of ra_serf?

I've been using it exclusively for years. It has been totally fine.

> Will we (again) attempt to make serf the
> default in 1.8?

It has been the default in the codebase for a few years. We changed the
default on the 1.7 branch. You should have been using it.

> I know there have been some ra_serf bugfixes since
> 1.7, but there are certainly still some important open issues

There is a single open issue that I believe warrants a fix for 1.8, and
that is the HTTP/1.0 proxy work. That has been tested with a pre-release
build of serf 1.1 for a new API. Before releasing that, I'm waiting on some
feedback from Apache OpenOffice, which won't arrive until after they get
past the insanity of their release this week. So when 1.1 is released, then
I'll enable the code to fix the proxy issue (it's in there, just not

> (not to
> mention unkown problems because ra_serf hasn't had enough coverage and
> problems aren't always adequately reported).

All software has unknown problems. I don't believe there are any more in
ra_serf than any other code. If you believe otherwise, then start filing

> If we want to make serf happen for 1.8, shouldn't we (as a community)
> spend more time on it then?

Everybody already should have been doing this for years.

> I'd hate for us to end up in the same
> difficult situation as with the 1.7 release: trying to make it the
> default but then realizing shortly before release that it isn't stable
> enough (partly because it hadn't seen enough coverage, and people
> didn't report problems so they could be fixed etc, etc...). In spite
> of the request in the 1.7-release notes for users to try out serf and
> report problems [1], I haven't seen many new reports ...

Because maybe it works? Ever consider that?

> I think we need some kind of community decision whether or not we'll
> go for it this time.

When we went with neon for 1.7, we said serf for 1.8. Do you have any
concrete information to change that choice?

> And if we go for ra_serf as the default, put much
> more effort into it to make it happen. Starting with agreeing on a set
> of requirements that we want to be satisfied before release, or
> something like that.

Requirements are fixing the 1.8 blocking issues. I say there is just the
proxy one, which is mostly done.

> FWIW: I personally think serf brings noticeable (performance)
> improvements for users (so it's not only a license/developer/...
> thing) [2]. But it's hard to measure, it depends on a lot of factors,
> and can differ between usecases. On the downside: it's not yet stable
> enough,

Why do you say it is not stable enough? Unfiled issues?

> and generates too many requests (generating too many logs on
> the server).

That is not a real-world issue, IMO. I have never heard a user complain,
ever, about the sizes of logfiles produced by the Apache HTTP Server, in
the 13.5 years I have been associated with the project. Do you have any
cases where people have complained?

> So I still see ra_serf having a lot of potential, and I
> hope it will become the default one day...

It is already the default.

> --
> Johan
> [1] http://subversion.apache.org/docs/release-notes/1.7.html#serf
> [2] On a Solaris build machine @work (Solaris 10 on x86 on ESX, with
> 1.6.17 client, 1.5.4 server (sorry, old stuff)), most interactions
> with the svn server are a lot faster when using serf than with neon.
> Things like ls, cat, log, mergeinfo, ... are all a lot faster (like
> 150ms vs. 900ms).

Upgrading your server will enable the faster HTTP sequences in both layers.
It might narrow that gap.

> Unfortunately, I can't use serf in general, because
> checkouts and updates crash sometimes (yeah, I need to investigate
> more, and report those ... first need to reproduce with a 1.7 client
> ...).

Filing bugs for both 1.6 and 1.7 are useful.

Separately, if you can somehow get me (temporary/occasional) access to any
Solaris box, that would be helpful. I have no access to one today.

> So in my scripts I sprinkle "config-options
> servers:global:http-library=serf" for all svn commands that I know
> will not crash (basically anything except checkout, export and
> update).

How many files in your working copy / export? We had a large working set
issue when these had tens of thousands of nodes. Fixed in 1.7.

> That made our buildscripts a lot faster on this machine. I
> don't know the reason for this perf difference, I don't see it on our
> Windows clients, nor on a physical Solaris 10 sparc machine. Maybe
> something to do with TCPIP parameters, network stack, actual
> connectivity (they're all on the same LAN though) ... for some reason
> neon is very expensive on this machine ...

I'd have to take a look (on tablet now), but this actually may be due to
needing temp files in neon for each incoming file. IOW, local I/O rather
than the network. Both the RA layers need temp files in certain cases due
to push/pull differences in APIs.

The other thing is that ra_serf can take advantage of multiple connections
on these checkout cases, to keep the server and network more fully-utilized.

Received on 2012-05-02 18:45:55 CEST

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