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

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

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 9 Mar 2011 19:14:17 +0300

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

-- 
Ivan Zhakov
Received on 2011-03-09 17:15:10 CET

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

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