From users-return-28093-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Fri Jun 28 03:51:24 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 D2BC2180607 for ; Fri, 28 Jun 2019 05:51:23 +0200 (CEST) Received: (qmail 82872 invoked by uid 500); 28 Jun 2019 03:51: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 82862 invoked by uid 99); 28 Jun 2019 03:51:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jun 2019 03:51:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E9D31C1AFB for ; Fri, 28 Jun 2019 03:51:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-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, KAM_SHORT=0.001, NUMERIC_HTTP_ADDR=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-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 (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id TKOlwADnLZ-Z for ; Fri, 28 Jun 2019 03:51:15 +0000 (UTC) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 00DEB5F419 for ; Fri, 28 Jun 2019 03:51:14 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id j19so4825821qtr.12 for ; Thu, 27 Jun 2019 20:51: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=b8rfGJv3g7+8SJoSW7+D0IpJ1mEQYYUuNZ91jiVU0Rs=; b=koPsUj8C2YSv6VzFEPDezekKTvPIOxmLRGBRJiYCl6odFmpOq+Q54KfT2wgwppQRwS svUG7cGp86o+OXXiJPTySfgJR4j+FAsPuoGFBbQPDZzRxDEBnzIDjv66NKouZG3yPyu+ pxvAw9Wp6Sh0hWWHYHnd70otGL5nXJK4v5Ue2QjFR3x3vy67CalBaBv3Yt1P4g7sDapu 0gSsjUOVPegTWzQaDCj9gscl40/6IifpiePuY+zoKBbKKH79nyPRzZSLn6d3xePo4fgU u8OXbPbTiUO5iA5mMfCd4XTgq0EHocy4sKbNVVCYFE4KhKsZ3TFTdSTLVazCVpMcEGKj Ki6Q== 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=b8rfGJv3g7+8SJoSW7+D0IpJ1mEQYYUuNZ91jiVU0Rs=; b=m7nvQm0RtnqEIYXlBIBgh35Nx8yDBR9rykV7oazkX0pa1JcC0SRtWzZAYJ23/8u8If 5yjjVPVLtLYnbLgEgKw5xGd0Yb5S3dF0lGNJS8nHoKaWyoSA0Dz/ZNOdFy5kF2qB7TM4 T5z816aBKnZfHkuYmkbEGZOCgvNlqSKnr6jnUsR7fTyrcI2NY3mSTvEQo9faX1XaTTby 33PIn7TP22TyHwRRxRg5gLRZBWBCOx2ESzBsReYjR984LqzZf2BpedHxOi8VJUB945cA YX8Y6fE8HvTQDFv9fxFJxk6zWzDBqYnSk9+JQ2SfL2Xz/IbDP6VDnUxVBEdNJ6NllMvL 161g== X-Gm-Message-State: APjAAAVh8T+pqUWYeGVgt3d28w3kCMs96f0vtfC067UDrttVscZwf893 j163CgFWS3pgZMiL/OPl02stV3rO+sWjdul57bJsfw== X-Google-Smtp-Source: APXvYqwZfmuNK0J3DO0t/NhSXT//00lfAUwowgEGSIdlt856UeLpZmk3s0TNK69qQVZ624pZNPrNHqVuSaFoA4RbONs= X-Received: by 2002:ac8:1a3c:: with SMTP id v57mr6230589qtj.339.1561693867650; Thu, 27 Jun 2019 20:51:07 -0700 (PDT) MIME-Version: 1.0 References: <785065892.20190613135937@am-soft.de> In-Reply-To: From: Thuan Seah Tan Date: Fri, 28 Jun 2019 13:50:30 +1000 Message-ID: Subject: Re: svn status and info slowness when multiple files are passed as args To: Johan Corveleyn Cc: Subversion , =?UTF-8?Q?Thorsten_Sch=C3=B6ning?= Content-Type: multipart/alternative; boundary="0000000000003aca7e058c5a304c" --0000000000003aca7e058c5a304c Content-Type: text/plain; charset="UTF-8" Thanks for the info. I did more tests and can confirm the issue appears to be a IPv6 vs IPv4 issue. I enabled the --prefer-ipv6 option on the svnserve command and running commands on checked out files that point to a domain name repository root were significantly faster. Alternatively relocating the project root from domain name to explicit IPv4 also helped. On Fri, Jun 28, 2019 at 4:37 AM Johan Corveleyn wrote: > On Wed, Jun 26, 2019 at 9:33 AM Thuan Seah Tan wrote: > > > > Apologies for the delay on this issue. I did more testing and the > following was my findings: > > > > svn info -r HEAD "svn://mysvnserver/1.10/test.txt" "svn:// name>/1.10/test2.txt" <-- slow > > svn info -r HEAD "svn://192.168.1.123/1.10/test.txt" "svn:// address of server>/1.10/test2.txt" <-- fast > > > > If I am not using the svn protocol and just passing in the file path on > disk, depending on how the files were checked out: > > > > if checked out using Tortoise SVN and specifying the repository server > as "svn://192.168.1.123": > > svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt" <-- fast > > > > if checked out using Tortoise SVN and specifying the address of the > server as "svn://mysvnserver": > > svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt" <-- slow > > > > Wondering if using the server name defaults to IPv6. I suppose that's up > to the router's configuration? When checking out files, is there something > added to the .svn folder that retains the knowledge of whether a file was > checked out using ipv4 or server name? > > > > Ok, so it's clearly a problem with the client first trying the IPv6 > address, to which svnserve doesn't respond in your case. Now, I don't > know a lot myself about how to deal with that situation (we don't use > svnserve, we're accessing our svn repository via https). Perhaps > someone else on this list has some experience, and can help a bit? > > Just a couple of thoughts: > - The fact that svn://mysvnserver first defaults to the IPv6 address > is entirely up to network configuration, I guess. Not sure if it's the > router, local DNS server, Windows networking configuration, ... as I > said, I don't know much in that area. But perhaps that's the easiest > "fix" for you: fix the network configuration so clients get connected > to the IPv4 address by default. > > - The .svn folder certainly retains knowledge of the exact URL it was > checked out from. It's visible when you run 'svn info' (showing the > working copy url). You can change that in an existing working copy by > running 'svn relocate' (see 'svn help relocate' for help), so you can > "connect" it with another URL pointing to the same repository. > > - Perhaps that thread I pointed to earlier contains some more > interesting information about what else you can do. > https://svn.haxx.se/users/archive-2018-06/0000.shtml > (for instance, I see things about starting up a second instance of > svnserve with the -6 option for listening on the IPv6 address) > > HTH, > -- > Johan > --0000000000003aca7e058c5a304c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the info. I did more tests and can confirm the = issue appears to be a IPv6 vs IPv4 issue.

I enabled the = --prefer-ipv6 option on the svnserve command and running commands on checke= d out files that point to a domain name repository root were significantly = faster. Alternatively relocating the project root from domain name to expli= cit IPv4 also helped.

On Fri, Jun 28, 2019 at 4:37 AM Johan Corveleyn = <jcorvel@gmail.com> wrote:
On Wed, Jun 26, 2= 019 at 9:33 AM Thuan Seah Tan <thuan@fmod.com> wrote:
>
> Apologies for the delay on this issue. I did more testing and the foll= owing was my findings:
>
> svn info -r HEAD "svn://mysvnserver/1.10/test.txt" "svn= ://<server name>/1.10/test2.txt" <-- slow
> svn info -r HEAD "svn://192.168.1.123/1.10/test.txt&= quot; "svn://<IPv4 address of server>/1.10/test2.txt" <-= - fast
>
> If I am not using the svn protocol and just passing in the file path o= n disk, depending on how the files were checked out:
>
> if checked out using Tortoise SVN and specifying the repository server= as "svn://192.168.1.123":
> svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt&= quot; <-- fast
>
> if checked out using Tortoise SVN and specifying the address of the se= rver as "svn://mysvnserver":
> svn info -r HEAD "C:/1.10/test.txt" "C:/1.10/test2.txt&= quot; <-- slow
>
> Wondering if using the server name defaults to IPv6. I suppose that= 9;s up to the router's configuration? When checking out files, is there= something added to the .svn folder that retains the knowledge of whether a= file was checked out using ipv4 or server name?
>

Ok, so it's clearly a problem with the client first trying the IPv6
address, to which svnserve doesn't respond in your case. Now, I don'= ;t
know a lot myself about how to deal with that situation (we don't use svnserve, we're accessing our svn repository via https). Perhaps
someone else on this list has some experience, and can help a bit?

Just a couple of thoughts:
- The fact that svn://mysvnserver first defaults to the IPv6 address
is entirely up to network configuration, I guess. Not sure if it's the<= br> router, local DNS server, Windows networking configuration, ... as I
said, I don't know much in that area. But perhaps that's the easies= t
"fix" for you: fix the network configuration so clients get conne= cted
to the IPv4 address by default.

- The .svn folder certainly retains knowledge of the exact URL it was
checked out from. It's visible when you run 'svn info' (showing= the
working copy url). You can change that in an existing working copy by
running 'svn relocate' (see 'svn help relocate' for help), = so you can
"connect" it with another URL pointing to the same repository.
- Perhaps that thread I pointed to earlier contains some more
interesting information about what else you can do.
https://svn.haxx.se/users/archive-2018-06/0000.s= html
(for instance, I see things about starting up a second instance of
svnserve with the -6 option for listening on the IPv6 address)

HTH,
--
Johan
--0000000000003aca7e058c5a304c--