Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B3F5E94E2 for ; Thu, 5 Jan 2012 18:02:46 +0000 (UTC) Received: (qmail 98875 invoked by uid 500); 5 Jan 2012 18:02:46 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 98827 invoked by uid 500); 5 Jan 2012 18:02:45 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 98820 invoked by uid 99); 5 Jan 2012 18:02:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2012 18:02:45 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tortoisesvn@gmail.com designates 74.125.83.43 as permitted sender) Received: from [74.125.83.43] (HELO mail-ee0-f43.google.com) (74.125.83.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jan 2012 18:02:38 +0000 Received: by eekd4 with SMTP id d4so736120eek.16 for ; Thu, 05 Jan 2012 10:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VhOlvEQPHh4qh4o+6migeWT/MvLgORxqRd5Oz1dE5jY=; b=gpTyxcZPhqG2yi4ltlvMEC/Wt2PUrxBcuYcJR2GfSMk/dR/xYquret3R2X70IFn+AZ /9XEnSzmZrC6HRFiigFvLPE9BUf32Iykj9DWJkDTv+sR+2GlgsYC4EDIwTkfI+CIgztQ DE4LaZw+x6lEC34xgbp1FFux6S42ZpzyXC4mI= Received: by 10.14.52.4 with SMTP id d4mr1104932eec.124.1325786538712; Thu, 05 Jan 2012 10:02:18 -0800 (PST) Received: from [192.168.0.197] (cable-static-20-197.rsnweb.ch. [88.84.20.197]) by mx.google.com with ESMTPS id t59sm236429339eeh.10.2012.01.05.10.02.16 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 10:02:17 -0800 (PST) Message-ID: <4F05E5A5.7090905@gmail.com> Date: Thu, 05 Jan 2012 19:02:13 +0100 From: =?UTF-8?B?U3RlZmFuIEvDvG5n?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Philip Martin CC: Konstantin Kolinko , Subversion Development Subject: Re: svn ls performance References: <4F04C1C7.1070503@gmail.com> <87ipkrj8qy.fsf@stat.home.lan> In-Reply-To: <87ipkrj8qy.fsf@stat.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 05.01.2012 01:25, Philip Martin wrote: > Konstantin Kolinko writes: > >> 2012/1/5 Stefan Küng: >>> Hi, >>> >>> Due to a report on the TSVN mailing list I found that the CL client has the >>> same problem: >>> 'svn list' takes forever in some situations. >>> I don't know what the problem exactly is, but it's easily reproducable: >>> >>> svn ls http://plugins.svn.wordpress.org/ -v --depth=immediates >>> prints one entry, then never returns (ok, maybe not never. But waiting 10 >>> minutes is not enough). >>> >>> however, an >>> svn ls http://plugins.svn.wordpress.org/ --depth=immediates >>> (same command as above, but without the verbose flag) returns the entries >>> almost immediately. >>> I don't think that simply fetching the verbose info could take so much >>> longer? >>> >>> This is with svn 1.7.2. >>> The same works fine with svn 1.6.6 - haven't tested with later 1.6 svn >>> clients since I don't have that version ready here on my machine. >>> >>> using serf instead of neon doesn't help. >>> >> >> http://plugins.svn.wordpress.org/ >> The page has a lot of subdirectories (nearly 26000) >> The server is 1.6.12. >> >> Using client 1.6.17 (built by CollabNet, 32-bit, on Windows) it >> printed the first line in 10 seconds, and never printed the rest. I >> waited for ~1 minute. (Ctrl+C did not help, I had to unplug the >> network cable) >> >> Using client 1.7.2 (from TortoiseSVN, 32-bit, on Windows) the result >> is the same: >> the first line in ~10 seconds, the rest of data - ~never. >> >> 1.6.17: Removing "--depth" option does not change anything. >> 1.6.17: Removing "-v" the result appears in ~15 seconds and then takes >> ~10 seconds to print the listing to the console. > > I created a repository with 10,000 subdirs: > > #!/bin/bash > for i in `seq 0 999`;do > svn mkdir -mm file://`pwd`/repo/A${i}{0,1,2,3,4,5,6,7,8,9} > done > > I measured the following times: > > client server ls -v ls > 1.6.6 1.6.12 43s 0.3s > 1.6.12 1.6.12 43s 0.3s > 1.7.3 1.6.12 43s 0.3s > 1.6.6 1.7.3 1.8s 0.5s > 1.6.12 1.7.3 1.8s 0.4s > 1.7.3 1.7.3 1.8s 0.4s > > I don't see any significant difference between clients (I'm using neon) > only between the servers. 1.7 is a major improvement in the verbose > case, probably due to the better FSFS in-memory caching. There is > perhaps a slight regression in the non-verbose case. > > As a side issue having 26,000 branches in the same directory is really > bad for repository size due to the absence of directory deltification. > My repository has 10,000 subdirs in 1,000 revisions and nothing else and > yet it takes 175MB of disk. The last commit, which adds 10 empty > subdirs, produces a rev file that is 347KB. Each commit to the > wordpress repository probably adds about 1MB to the repository just > rewriting that 26,000 branch directory. > Hmm - strange. I've had significant different timings for 1.6.6 and 1.7.2. But I've tried 1.6.6 right after 1.7.2, so maybe there was some caching involved? I'll have to do some more testing. But could the performance be somewhat improved? After all, without the verbose flag the result is available much, much faster. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/> The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net