Re: svn status and info slowness when multiple files are passed as args
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 >
Re: svn status and info slowness when multiple files are passed as args
Guten Tag Thuan Seah Tan, am Donnerstag, 13. Juni 2019 um 09:25 schrieben Sie: > [...]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". As you are running Windows, disabling all kinds of AV-software at least for the directories belonging to your SVN-repos would be the first thing I'm trying. If that doesn't change a thing, use Process Monitor to see where the slowness comes from. That reports exactly which I/O happens where and how long it takes. https://docs.microsoft.com/en-us/sysinternals/downloads/procmon https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: svn status and info slowness when multiple files are passed as args
On Thu, Jun 13, 2019 at 1:59 PM Thorsten Schöning wrote: > > Guten Tag Thuan Seah Tan, > am Donnerstag, 13. Juni 2019 um 09:25 schrieben Sie: > > > [...]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". > > As you are running Windows, disabling all kinds of AV-software at > least for the directories belonging to your SVN-repos would be the > first thing I'm trying. If that doesn't change a thing, use Process > Monitor to see where the slowness comes from. That reports exactly > which I/O happens where and how long it takes. > > https://docs.microsoft.com/en-us/sysinternals/downloads/procmon > https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite > > Mit freundlichen Grüßen, > > Thorsten Schöning Hm, I don't think the problem is "local IO slowdown" (like with antivirus). That wouldn't explain "svn info -r HEAD -R directory" taking 1-2 seconds (in the initial report by the OP). @Thuan: has it always been that slow? My intuition tells me to take a look at IPv4 vs. IPv6 problems. See for example this thread on this mailinglist: https://svn.haxx.se/users/archive-2018-06/.shtml Also, in response to your question: >> 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? Yes, there is "base client code" shared by all these implementations: TortoiseSVN, Visual SVN, commandline SVN, ... they all share the same underlying svn libraries that are maintained by this project, Apache Subversion (of which you've reached the users mailinglist). As for "reporting the issue to the team maintaining the project": there is not really a dedicated "team" waiting to work on issues. There are project members of the Apache Subversion project (some of them are also reading this mailinglist -- I am one of them). Those project members are just individuals like yourself, sometimes working on things they care about (for themselves or for their employers) ... such is the nature of FOSS. So reporting an issue or suggesting an improvement will not magically make it happen. On the other hand, we very much appreciate clear reports of issues or suggestions -- those are definitely valuable contributions. In other words: yes, it could be a good idea to officially write this down into an issue in the issue tracker [1] (but we're still a bit fuzzy on the details, I think we still need some further discussion / troubleshooting), but to make expectations clear: reporting it does not magically make it happen :-). [1] http://subversion.apache.org/reporting-issues.html Thanks, -- Johan
