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

Jenkins.getUser(...) is debilitatingly slow with a large number of users

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • core
    • None
    • 1.554.1 with JENKINS-22822

      We've got 1026 users on builds.apache.org, and when you try to view a user or go through a user's views, etc, load time is abominable most of the time - ~54 seconds or so in the example below. While we're seeing a lot of what might be i/o related slowness in other areas, this seems kind of insane. Does User.getAll() really need to reload every user's config.xml every 10 seconds?

        1. 20140603-023516.013.txt
          99 kB

          [JENKINS-23281] Jenkins.getUser(...) is debilitatingly slow with a large number of users

          Andrew Bayer created issue -

          Andrew Bayer added a comment -

          Might be worth mentioning that this is on a zfs volume...

          Andrew Bayer added a comment - Might be worth mentioning that this is on a zfs volume...

          Andrew Bayer added a comment -

          And something is messed up on that volume, apparently - stat i/o and the like is really nasty on it in general, based on tests from outside Jenkins. So this may not be as bad as it seemed.

          Andrew Bayer added a comment - And something is messed up on that volume, apparently - stat i/o and the like is really nasty on it in general, based on tests from outside Jenkins. So this may not be as bad as it seemed.

          Oleg Nenashev added a comment -

          Does User.getAll() really need to reload every user's config.xml every 10 seconds?

          No idea why Jenkins performs such loading, but it's a legacy behavior, hence we cannot just remove it.
          I propose to add a switch variable, which will make Jenkins to load users on the startup only.

          Oleg Nenashev added a comment - Does User.getAll() really need to reload every user's config.xml every 10 seconds? No idea why Jenkins performs such loading, but it's a legacy behavior, hence we cannot just remove it. I propose to add a switch variable, which will make Jenkins to load users on the startup only.

          Oleg Nenashev added a comment -

          In addition, User.getAll() seems to be unsafe against multiple caller threads.

          Oleg Nenashev added a comment - In addition, User.getAll() seems to be unsafe against multiple caller threads.

          Daniel Beck added a comment -

          abayer: Was this issue caused by your disk being complete crap?

          Daniel Beck added a comment - abayer: Was this issue caused by your disk being complete crap?

          Andrew Bayer added a comment -

          Yeah, but I'd say some work should be done regardless - the complete crapness of the disk exposed the problem, but there's still some brutal inefficiencies.

          Andrew Bayer added a comment - Yeah, but I'd say some work should be done regardless - the complete crapness of the disk exposed the problem, but there's still some brutal inefficiencies.
          Daniel Beck made changes -
          Priority Original: Critical [ 2 ] New: Major [ 3 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 155846 ] New: JNJira + In-Review [ 179140 ]
          Oleg Nenashev made changes -
          Link New: This issue is related to JENKINS-47718 [ JENKINS-47718 ]

            Unassigned Unassigned
            abayer Andrew Bayer
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: