On Wed, Mar 9, 2011 at 18:53, Philip Martin <philip.mar...@wandisco.com> wrote:
> 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.
>
That's really interesting. Could you provide similiar strace for neon?
--
Ivan Zhakov
