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

Ludicrously slow load time [with lazyloading]

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • cppcheck-plugin
    • Latest Jenkins, Linux /redacted hostname/ 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux, SuSe most probably.

      CPPcheck might be taking over 3,823,295ms loading a 500-job project on account of, possibly, one erroneous file. Or something. Long story short, I used the JavaMelody monitoring in Jenkins and saw that cppCheckResult was taking a HELL of a long time with one method call, and other attempts to find other ways to do this or ways around the bug have given, at best, nothing.

      Handling GET /job/-------/cppcheckResult/graph : RequestHandlerThread24
      /job/-------/cppcheckResult/graph? GET
      3 823 295 0 0 com.thoughtworks.xstream.converters.reflection.FieldDictionary.fieldOrNull(FieldDictionary.java:113)

      It's a "replicatable" problem on our servers, but since it's internal stuff I can't link you to it.

          [JENKINS-17363] Ludicrously slow load time [with lazyloading]

          Renaud Lepage created issue -
          Renaud Lepage made changes -
          Environment Original: Latest Jenkins, Linux ecamolx0800.mo.ca.am.ericsson.se 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux, SuSe most probably. New: Latest Jenkins, Linux /redacted hostname/ 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux, SuSe most probably.
          Labels Original: ridiculous New: slow

          Jan Klass added a comment -

          We experience the same problem; very high loading times.
          The last time we worked around the issue by downgrading Jenkins and the CPPCheck plugin.

          I updated to Jenkins LTS again, and updated the CPPCheck plugin, and the issue occurs again.

          The long loading time occurs when the cppcheckResult/graph is requested as well.
          Requesting it directly there is no problem once downloaded; the not modified return HTTP status code works as expected.
          Same for the jobs page with the cppcheck result publishing, which contains this image. Once cached when the request does not lead to a retransmission of the image it works fine.

          When the image is seemingly generated one CPU core is used for 100 %. Other independant requests seem to be affected as well.

          So my guess is that

          • the graph image is not cached or the cache does not work/notice nothing changed
          • the image is regenerated in a very non performant way

          Jan Klass added a comment - We experience the same problem; very high loading times. The last time we worked around the issue by downgrading Jenkins and the CPPCheck plugin. I updated to Jenkins LTS again, and updated the CPPCheck plugin, and the issue occurs again. The long loading time occurs when the cppcheckResult/graph is requested as well. Requesting it directly there is no problem once downloaded; the not modified return HTTP status code works as expected. Same for the jobs page with the cppcheck result publishing, which contains this image. Once cached when the request does not lead to a retransmission of the image it works fine. When the image is seemingly generated one CPU core is used for 100 %. Other independant requests seem to be affected as well. So my guess is that the graph image is not cached or the cache does not work/notice nothing changed the image is regenerated in a very non performant way

          Jan Klass added a comment -

          The issue occurs when there are a lot of job builds, and only a few recent ones have data.

          Removing all builds from the job (in the file system) the graph seems to work fine again.
          I guess it is missing robustness - handling invalid data or job (older) builds with no (or outdated?) cppcheck data.

          Jan Klass added a comment - The issue occurs when there are a lot of job builds, and only a few recent ones have data. Removing all builds from the job (in the file system) the graph seems to work fine again. I guess it is missing robustness - handling invalid data or job (older) builds with no (or outdated?) cppcheck data.

          Ruben van Staveren added a comment -

          How many messages are logged in cppcheck ? check your build.xml for large sizes. In that case it is related to JENKINS-19437. See also https://groups.google.com/forum/#!topic/jenkinsci-users/z66arr7QN1M

          Ruben van Staveren added a comment - How many messages are logged in cppcheck ? check your build.xml for large sizes. In that case it is related to JENKINS-19437 . See also https://groups.google.com/forum/#!topic/jenkinsci-users/z66arr7QN1M

          Ruben van Staveren added a comment -

          Depending on how many messages are logged with cppcheck, it might be related to huge per run build.xml logs

          Ruben van Staveren added a comment - Depending on how many messages are logged with cppcheck, it might be related to huge per run build.xml logs
          Ruben van Staveren made changes -
          Link New: This issue is related to JENKINS-19437 [ JENKINS-19437 ]
          Ruben van Staveren made changes -
          Link New: This issue is related to JENKINS-19437 [ JENKINS-19437 ]
          Michal Turek made changes -
          Assignee Original: Gregory Boissinot [ gbois ] New: Michal Turek [ mixalturek ]
          Michal Turek made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

            mixalturek Michal Turek
            cybikbase Renaud Lepage
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: