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

Re: ra_serf in Windows binaries

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 31 Jul 2008 19:25:01 -0400

On Thu, Jul 31, 2008 at 7:01 PM, Kenneth Porter <shiva_at_sewingwitch.com> wrote:
> --On Thursday, July 31, 2008 6:23 PM -0400 Mark Phippard
> <markphip_at_gmail.com> wrote:
>
>> Unfortunately, you heard wrong. Serf is not faster. It's goal is to
>> get "close enough" in speed to Neon to be a good alternative.
>
> So what's the point of ever using it? What makes it preferable to Neon?
>
> There was some indication in stuff I'd read that it does pipelined requests,
> which seems like it would make things somewhat faster.

It does use pipelining, that is one of the ways it gets performance
near Neon. The difference is that if you are checking out 100 files,
with Serf that is 100 GET requests and with Neon it is a single custom
REPORT request.

Serf is Apache license vs. LGPL for Neon. It is also written using
APR like the rest of Subversion and Apache. So it in theory makes it
easier for the developers to hack on.

I think the caching was a big design point. Take a large repository
like the Apache repos. In theory they can load-balance some Squid
cache servers in front of their repository and off-load a huge amount
of the work to the cache servers. You cannot do this with Neon. So
overall performance would likely become better.

Serf lacks a lot of the advanced features that Neon has such as SSPI
authentication, possibly client certs, support for different proxies
etc.

Serf is probably stable enough to use regularly, but it is not without bugs.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-01 01:25:25 CEST

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

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