From users-return-28075-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Thu Jun 13 07:26:19 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9BA0A18064E for ; Thu, 13 Jun 2019 09:26:19 +0200 (CEST) Received: (qmail 49880 invoked by uid 500); 13 Jun 2019 07:26:18 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 49839 invoked by uid 99); 13 Jun 2019 07:26:17 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jun 2019 07:26:17 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 3E9A1C22B4 for ; Thu, 13 Jun 2019 07:26:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.003 X-Spam-Level: ** X-Spam-Status: No, score=2.003 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=fmod-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id aYXgOJuWYNSA for ; Thu, 13 Jun 2019 07:26:15 +0000 (UTC) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id BAEA65F1BE for ; Thu, 13 Jun 2019 07:26:14 +0000 (UTC) Received: by mail-qt1-f174.google.com with SMTP id h21so21383364qtn.13 for ; Thu, 13 Jun 2019 00:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmod-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z+X9/0fZfg1rE3bSnZrTNm3kFoW/XCE+pYEE5JQPZbA=; b=bhvcLWN4IDvPrrDAoG67+abNH7Qbgrt/iPvVTnPyOgC0baYlSQR/s7RCHQtSMwVTUZ tNy3Fpv6lNOvu5jii0Al/DhI1JioctzyazSz4Cj5czpb93j/B102hdsXA3CBgqYEqZXv qcW4HJt0KtKQFT2mnruh9LJd7MVhBS8H3No1RfHNN3Iw86nrl1zp5+rT6RI25dlA283P T2hjYldyaJJdHvc3MfQf0dE6ExBcuPCKBsTZ7DEYQGPIaCCudjxYQFs6mqmsGX0oGu2R GDry33cy3MeXQy7+0M5uGltDvz6UvI55ajiLFe04cLSkP60Eyvo77zOK85cb9H/mzxrj VZPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z+X9/0fZfg1rE3bSnZrTNm3kFoW/XCE+pYEE5JQPZbA=; b=JllMBYo7rKZwIJ5n0E6VRp7Qfwl5N+ydsWvtdpMSO7nBgay3n80bW4YyE2AkPsi60T kxSlu1gTh9sSUUbpl2J8Q1caXPBf/eY1UQfpdDiD4dlfPaLqgebaz225HwBscg5L6TYb kgMGMLtOjOvEE6C6F5124erS6fBwy+TAPenhBpZ/WJQjLY8rr6SFUdBNdvxStB27nq12 A0ttPvTLiIJsx3LT4zIH/iJan25+0MSRmui5LvUwNvbAW3Nl94nlvOe15w6ZKr6zu8jZ 7O6PgPVwBaDtUUB6IANlyN828R6Nlg1V1p1GDfLsG4W8/uqAALcp6Stfi2nv3RCoj2AC XgVw== X-Gm-Message-State: APjAAAXn3iSVddmfrke34YVptOjp4A5LVBFhjoHlk9y+FI+GFXOCm2TX KPvRwkUyGO2zeawcjhSFRRSemCKumjzq38vokhBPbQ== X-Google-Smtp-Source: APXvYqysfzjabovKNYX86n+GNotVj3DUNZyMTKNvzswr/gVWPHJDytrRqgMjhIN4vU2ntjVHefI7uy/ug8sg659Rahw= X-Received: by 2002:ac8:85b:: with SMTP id x27mr72474866qth.324.1560410773621; Thu, 13 Jun 2019 00:26:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thuan Seah Tan Date: Thu, 13 Jun 2019 17:25:36 +1000 Message-ID: Subject: Re: svn status and info slowness when multiple files are passed as args To: Johan Corveleyn Cc: Subversion Content-Type: multipart/alternative; boundary="000000000000dda40e058b2f7163" --000000000000dda40e058b2f7163 Content-Type: text/plain; charset="UTF-8" Hi Johan, I am using Tortoise SVN 1.12.0 r1857323. When you say it could be optimized in the client, I take it that is up to the team maintaining the project (e.g. Tortoise SVN, Visual SVN, etc) and I should report the issue to them? Or is there some base client code used by these implementations? I ran 'svn info --show-item url' as requested and the url showed the svn:// protocol. I also tried running 'info -r HEAD' on files that are checked out on the PC that the server was running, and it is just as slow. Both the url and repository root fields started with "svn://localhost". On Wed, Jun 5, 2019 at 8:05 PM Johan Corveleyn wrote: > On Wed, Jun 5, 2019 at 4:15 AM Thuan Seah Tan wrote: > > > > Thanks for the response. I did more testing on the 1.12.0 server, and it > seems it's only those command options that I think would require querying > the server is experiencing the slow down: > > > > e.g. > > svn status --show-updates directory/file1.txt directory/file2.txt > directory/file3.txt <-- this took about 3 seconds and seems to scale > according to the number of files as it outputs "Status against revision" > for each file. > > svn status --show-updates directory <-- this took about 1-2 seconds but > only output "Status against revision" once. > > > > svn info -r HEAD directory/file1.txt directory/file2.txt > directory/file3.txt <-- this took about 3 seconds and seems to scale > according to the number of files and display info for each file at the rate > of 1 file per second > > svn info -r HEAD -R directory <-- this took about 1-2 seconds even > though the entire directory has 17 files and just outputs info for 17 files > in one hit > > > > The server is on another machine in my local network and both running > Windows 10 Pro. Not entirely sure the filesystem you are referring to, but > the drive with the repository is running NTFS. > > Is your client also version 1.12.0? Running 'svn --version' on the > client will tell. > It's just to eliminate that this was possibly optimized on the client > side in recent versions. > > A couple of other things come to mind: > > - It's possible that 'svn status --show-updates X Y Z' opens > (sequentially) 3 separate connections / sessions to the server, > instead of only 1. Same for your 'svn info -r HEAD' example. That's > something that could possibly be optimized in the client. > > - How come it even takes 1-2 seconds for a single 'status > --show-updates' or 'info -r HEAD' request? That's extremely slow, > especially since you're saying it's all on a local network. Is it fast > if you create a working copy with a file:/// URL directly on the > server, and perform those commands there (it should be fast)? What > protocol are client and server using? Running 'svn info --show-item > url' on your working copy should tell. If it's https://, maybe there > is some problem / slowdown when opening a new SSL socket? Or > performing LDAP authentication on the server side. If it's svn://, > maybe there is a problem with IP v6 vs. IP v4. > > -- > Johan > --000000000000dda40e058b2f7163 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Johan,

I am using Tortoise SVN 1.12.= 0 r1857323. When you say it could be optimized in the client, I take it tha= t is up to the team maintaining the project (e.g. Tortoise SVN, Visual SVN,= etc) and I should report the issue to them? Or is there some base client c= ode used by these implementations?

I ran 'svn = info --show-item url' as requested and the url showed the svn:// protoc= ol. I also tried running 'info -r HEAD' on files that are checked o= ut on the PC that the server was running, and it is just as slow. Both the = url and repository root fields started with "svn://localhost".

On Wed, Jun 5, 2019 at 8:05 PM Johan Corveleyn <jcorvel@gmail.com> wrote:
On Wed, Jun 5, 2019 at 4= :15 AM Thuan Seah Tan <thuan@fmod.com> wrote:
>
> Thanks for the response. I did more testing on the 1.12.0 server, and = it seems it's only those command options that I think would require que= rying the server is experiencing the slow down:
>
> e.g.
> svn status --show-updates directory/file1.txt directory/file2.txt dire= ctory/file3.txt <-- this took about 3 seconds=C2=A0 and seems to scale a= ccording to the number of files as it outputs "Status against revision= " for each file.
> svn status --show-updates directory <-- this took about 1-2 seconds= but only output "Status against revision" once.
>
> svn info -r HEAD directory/file1.txt directory/file2.txt directory/fil= e3.txt <-- this took about 3 seconds and seems to scale according to the= number of files and display info for each file at the rate of 1 file per s= econd
> svn info -r HEAD -R directory <-- this took about 1-2 seconds even = though the entire directory has 17 files and just outputs info for 17 files= in one hit
>
> The server is on another machine in my local network and both running = Windows 10 Pro. Not entirely sure the filesystem you are referring to, but = the drive with the repository is running NTFS.

Is your client also version 1.12.0? Running 'svn --version' on the<= br> client will tell.
It's just to eliminate that this was possibly optimized on the client side in recent versions.

A couple of other things come to mind:

- It's possible that 'svn status --show-updates X Y Z' opens (sequentially) 3 separate connections / sessions to the server,
instead of only 1. Same for your 'svn info -r HEAD' example. That&#= 39;s
something that could possibly be optimized in the client.

- How come it even takes 1-2 seconds for a single 'status
--show-updates' or 'info -r HEAD' request? That's extremely= slow,
especially since you're saying it's all on a local network. Is it f= ast
if you create a working copy with a file:/// URL directly on the
server, and perform those commands there (it should be fast)? What
protocol are client and server using? Running 'svn info --show-item
url' on your working copy should tell. If it's https://, maybe ther= e
is some problem / slowdown when opening a new SSL socket? Or
performing LDAP authentication on the server side. If it's svn://,
maybe there is a problem with IP v6 vs. IP v4.

--
Johan
--000000000000dda40e058b2f7163--