On Jul 9, 2013 12:52 PM, "Ben Reser" <ben_at_reser.org> wrote:
>
> On Tue, Jul 9, 2013 at 12:55 AM, Ben Reser <ben_at_reser.org> wrote:
> > Have we considered just turning off chunked requests entirely until
> > Serf has a fix to automatically detect and handle servers that don't
> > support chunked requests? I've seen a lot of discussion about the
> > cost of doing an extra round trip to detect if we can use chunked
> > encoding, but I haven't seen anyone comparing the performance of the
> > client with and without chunked requests.
>
> Okay talked with Ivan and Lieven on IRC and they explained why this
> isn't an option. Essentially Serf isn't as efficient as Neon was with
> doing CL requests. We produce a temp file with the body, then send
> the data to serf which would produce another temp file and calculate
> the size. Which makes this suggestion a bad idea.
For those on the list who didn't hear why...
Neon is synchronous, so the app (svn) writes into Neon, which writes the
data into the socket.
Serf is asynchronous, and can manage many connections at once. Effectively,
it uses a callback when a connection is available for writing. The callback
provides data, and it gets written to the socket. In our case, the app
writes to a temp file, and the callback reads from that file.
We can optimize some requests by using spillbuf. Data will stay in memory,
but spill to a file if it gets too large. Of course, we don't want 100,000
spillbufs at 1M each. But there are ways to figure it out, or only requests
that won't be too numerous.
Another possibility is for the callback to generate the request on demand,
rather than having the app write it synchronously. This is my preferred
approach, but much of svn's APIs are push-based, making this difficult.
Cheers,
-g
Received on 2013-07-09 20:34:07 CEST