Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-2001

SVN check out slow performance issue - REGRESSION 1.419 to 1.421

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: Sun, OS: Solaris

      The Subversion checkout in Hudson's continuous build is slow. Despite setting
      the checkout to run against a memory based Solaris file system, the checkout is
      still acting as slowly as to a regular filesystem. For example, the Subversion
      checkout for a memory based Solaris file system took just 1 minutes and 30
      seconds against 7 minutes and 9 seconds for Hudson's continuous build checkout
      into a memory based Solaris file system (more than 4.5 times slower). Another
      example, the Subversion checkout from NetBeans IDE took only 3 minutes and it
      was done into harddisk file system which faster for 2 times comparing with
      Hudson checkout into a memory based Solaris file system.

          [JENKINS-2001] SVN check out slow performance issue - REGRESSION 1.419 to 1.421

          The original problem reported by ssburlg and the later addition by pgweiss are
          likely different as they involve different transports.

          In 1.260 I fixed a bug in SVNKit, which was breaking the use of persistent HTTP
          connections entirely. So hopefully this fixes the problem reported by ssburlg.

          Also in 1.260, we bumped up SVNKit to 1.2.0 release version, and one of the
          changelogs include svn+ssh performance improvement, which hopefully addresses
          the problem reported by pgweiss.

          If the new version won't show enough performance improvements, please feel free
          to reopen.

          Kohsuke Kawaguchi added a comment - The original problem reported by ssburlg and the later addition by pgweiss are likely different as they involve different transports. In 1.260 I fixed a bug in SVNKit, which was breaking the use of persistent HTTP connections entirely. So hopefully this fixes the problem reported by ssburlg. Also in 1.260, we bumped up SVNKit to 1.2.0 release version, and one of the changelogs include svn+ssh performance improvement, which hopefully addresses the problem reported by pgweiss. If the new version won't show enough performance improvements, please feel free to reopen.

          ssburlg added a comment -

          The new version(1.260) doesn't showed performance improvements. Moreover, I
          experienced performance degradation, when I ran job which did just check out and
          it took 12 minutes, comparing with 9 minutes 22 second for version 1.230...

          So, I downgraded Hudson back to 1.230.

          ssburlg added a comment - The new version(1.260) doesn't showed performance improvements. Moreover, I experienced performance degradation, when I ran job which did just check out and it took 12 minutes, comparing with 9 minutes 22 second for version 1.230... So, I downgraded Hudson back to 1.230.

          bhoyt added a comment -

          I'm seeing this issue in 1.262. Subversion checkouts from a master are taking nearly 35 minutes, while
          the same checkout from the command line svn client on that master zips along in just a few minutes.
          This is a svn+ssh URL.

          bhoyt added a comment - I'm seeing this issue in 1.262. Subversion checkouts from a master are taking nearly 35 minutes, while the same checkout from the command line svn client on that master zips along in just a few minutes. This is a svn+ssh URL.

          ijuma added a comment -

          Might be worth importing the newest SVNKit (1.2.2) to see if it helps.

          ijuma added a comment - Might be worth importing the newest SVNKit (1.2.2) to see if it helps.

          pgweiss added a comment -

          I am not optimistic about ever getting speeds in SVNKit up to anywhere near
          what they are for the regular svn client. I know Kohsuke is not in favor of
          this, but I think the only way to address the speed issue is to have Hudson use
          the command line client directly. Or, we can learn to live with the slow
          speeds.

          pgweiss added a comment - I am not optimistic about ever getting speeds in SVNKit up to anywhere near what they are for the regular svn client. I know Kohsuke is not in favor of this, but I think the only way to address the speed issue is to have Hudson use the command line client directly. Or, we can learn to live with the slow speeds.

          ijuma added a comment -

          As far as I am concerned, the speed we had at version 1.230 is good enough and
          that used SVNKit if I understand correctly.

          ijuma added a comment - As far as I am concerned, the speed we had at version 1.230 is good enough and that used SVNKit if I understand correctly.

          The performance issue on Solaris is fixed. See issue #3702.

          Kohsuke Kawaguchi added a comment - The performance issue on Solaris is fixed. See issue #3702.

          Peter Wolanin added a comment -

          We have seen a significant regression in svn checkout performance updating from 1.419 to 1.421. With the former our code checkout out in about 2.5 minutes vs with 1.421 it is not complete after 9.5 min and then consistently fails with SSL timout errors.

          Since I know the subversion plugin itself did not change between those releases, it must be affected by SSL handling or other http processing in Jenkins.

          Peter Wolanin added a comment - We have seen a significant regression in svn checkout performance updating from 1.419 to 1.421. With the former our code checkout out in about 2.5 minutes vs with 1.421 it is not complete after 9.5 min and then consistently fails with SSL timout errors. Since I know the subversion plugin itself did not change between those releases, it must be affected by SSL handling or other http processing in Jenkins.

          Peter Wolanin added a comment -

          Attached is an example of the errors that appear in the console output.

          Peter Wolanin added a comment - Attached is an example of the errors that appear in the console output.

          sbernaud added a comment -

          Well, I'm not sure it's exactly related to the current issue, but I've always (> 1 year) seen slower SVN checkouts on my debian lenny 64 slave (10 times slower than a checkout in a console, and about 10 times slower too than a checkout on another slave, say debian etch 32, squeeze 64 or RHEL 5.6).

          Recently we added another Lenny 64 slave and checkouts are slow there too. It may be related to the way we configure our lenny64, but my guess is it's related to a version of something that makes checkouts slower.

          technical details :
          I'm running 1.411. The master is inside a Tomcat 5.5 instance. No jobs on the master.

          svn server is accessed via svn://localhost/REPO-NAME URLs scheme (in a previously openned ssh tunnel).

          Our JRE versions :
          -----------------
          Lenny64
          java version "1.6.0_22"
          Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
          Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

          Lenny64 (second host)
          java version "1.6.0_26"
          Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
          Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

          Etch32
          java version "1.6.0_03"
          Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
          Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

          Squeeze64
          java version "1.6.0_18"
          OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~squeeze1)
          OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

          RHEL 5.6
          java version "1.6.0_17"
          OpenJDK Runtime Environment (IcedTea6 1.7.10) (rhel-1.20.b17.el5-x86_64)
          OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

          sbernaud added a comment - Well, I'm not sure it's exactly related to the current issue, but I've always (> 1 year) seen slower SVN checkouts on my debian lenny 64 slave (10 times slower than a checkout in a console, and about 10 times slower too than a checkout on another slave, say debian etch 32, squeeze 64 or RHEL 5.6). Recently we added another Lenny 64 slave and checkouts are slow there too. It may be related to the way we configure our lenny64, but my guess is it's related to a version of something that makes checkouts slower. technical details : I'm running 1.411. The master is inside a Tomcat 5.5 instance. No jobs on the master. svn server is accessed via svn://localhost/REPO-NAME URLs scheme (in a previously openned ssh tunnel). Our JRE versions : ----------------- Lenny64 java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) Lenny64 (second host) java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Etch32 java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) Squeeze64 java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~squeeze1) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) RHEL 5.6 java version "1.6.0_17" OpenJDK Runtime Environment (IcedTea6 1.7.10) (rhel-1.20.b17.el5-x86_64) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

            Unassigned Unassigned
            ssburlg ssburlg
            Votes:
            7 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: