Re: Subversion trunk (r1078338) HTTP(/WC?) performance problems?

Philip Martin <philip.martin_at_wandisco.com> writes:

> So both serf-0.3 and serf-0.7 are slower than neon.

I've been doing a little investigation. Start with a directory
containing 100 text files:

rm -rf zz;mkdir zz;for i in `seq 0 99`;do printf "abc" > zz/f$i;done

Import that directory using serf and neon and the times are broadly
similar, about half a second, with neon being marginally faster. Now
switch to 100 binary files:

rm -rf zz;mkdir zz;for i in `seq 0 99`;do printf "\x01\x02\x03" > zz/f$i;done

The import over neon is a bit slower, an extra quarter second, because
of the PROPSET for each file to set svn:mime-type. However the import
over serf is much slower, over 4 seconds.

Using "strace -rT" I can see that nearly all the extra time used by serf
compared to neon is inside the system call epoll_wait. For each file
serf does:

   writev("PUT")
   epoll_ctl()
   epoll_ctl()
   epoll_wait()
   read()
   munmap()
   epoll_ctl()
   epoll_ctl()
   epoll_wait()
   writev("PROPPATCH")
   epoll_ctl()
   epoll_ctl()
   epoll_wait()
   read()

and that last epoll_wait is orders of magnitude slower than all the
other system calls, at over 0.04s. Multiply that by 100 and it accounts
for excess time used by serf over neon.

I don't know why that system call takes so long, but that's where the
extra time goes.

-- 
Philip