Philip Martin <philip.mar...@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
