Last modified: 2014-11-18 17:39:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T72671, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70671 - CI browser test dashboard takes 100 seconds to appear on first load
CI browser test dashboard takes 100 seconds to appear on first load
Status: NEW
Product: Wikimedia
Classification: Unclassified
Continuous integration (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-10 18:30 UTC by spage
Modified: 2014-11-18 17:39 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description spage 2014-09-10 18:30:27 UTC
In the last few days, when I visit https://integration.wikimedia.org/ci/view/BrowserTests/ it redirects to  https://integration.wikimedia.org/ci/view/BrowserTests/view/-Dashboard/ which takes over 1.5 minutes to appear. Thereafter reloads are much faster.

It definitely was not this slow in the past. The redirect page now includes two graphs as well as the build queue and list of browser tests, maybe their libraries slow it down. If that's the problem then perhaps https://integration.wikimedia.org/ci/view/BrowserTests/ should not go to a page with these graphs.

The slowness is in both Firefox 32 and chromium 37 on Ubuntu
Comment 1 Antoine "hashar" Musso (WMF) 2014-09-17 14:39:04 UTC
The Jenkins dashboard loads the history of all builds on the first request. Jenkins save each build result as a standalone XML file and the server running Jenkins has slow disk I/O.

So, on first access the dashboard ends up loading thousands of files from disk. Once it is loaded, it is kept in memory for a while.

I am tempted to wontfix this bug.  A better solution would be to generate a dashboard by ourself and asynchronously but I don't think it is worth the effort.
Comment 2 spage 2014-10-16 03:25:41 UTC
I don't expect miracles :) but it's getting worse.  The last few times I've loaded the dashboard it times out altogether and I have to reload to get it to appear.

* Could I have a dumb cron job that requests the dashboard every "a while"? Would that hurt other clients of the server?
* Can we build dashboards for individual sets of tests like the [fl] and [ve] tabs that were in the cloudbees dashboard?
Comment 3 Antoine "hashar" Musso (WMF) 2014-10-29 11:41:45 UTC
What we could do is discard old build results after a given time. I am not sure whether we need to keep them after say 15 days.
Comment 4 Antoine "hashar" Musso (WMF) 2014-10-29 15:29:36 UTC
I have proposed the idea of reducing the browser tests history to the QA mailing list: https://lists.wikimedia.org/pipermail/qa/2014-October/002043.html
Comment 5 Željko Filipin 2014-10-29 15:42:09 UTC
(In reply to Antoine "hashar" Musso (WMF) from comment #3)
> What we could do is discard old build results after a given time. I am not
> sure whether we need to keep them after say 15 days.

+1
Comment 6 Greg Grossmeier 2014-11-18 17:16:34 UTC
"Jenkinks UI slow due to constant build record loading"
https://issues.jenkins-ci.org/browse/JENKINS-15858

Last comment:
"fixed in 2.8"

We're on Jenkins ver. 1.580.1
Comment 7 Greg Grossmeier 2014-11-18 17:38:54 UTC
From Zeljko:
Dashboard View, jenkins extension, we have version 2.9.4, performance bug should be fixed in 2.8


I'm wrong :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links