<div dir="ltr">1400 builders looks like a lot indeed!<div><br></div><div>Even with buildbot nine, we will probably need to optimize a little bit more the UI requests in order to display the builder page.<div>You will need to download 100k just to fetch the list of builders<br><br><div>The waterfall or builder page is for me really not useful when you have that much builders (eight or nine)</div>I think you would probably require a specific dashboard is order to split your builder matrix.</div><div><br></div><div>Buying new cores is not something I would recommend, as buildbot is fundamentally monothreaded.</div><div>On buildbot eight database is really about the buildrequests, and changes. I dont think that switching to mysql will help at all loading waterfall.</div><div>The best for you is to run <a href="https://pypi.python.org/pypi/statprof/">https://pypi.python.org/pypi/statprof/</a> over manhole (<a href="http://docs.buildbot.net/latest/manual/cfg-global.html#manhole">http://docs.buildbot.net/latest/manual/cfg-global.html#manhole</a>)</div><div>will definitly tell you were buildbot's code is hanging.</div><div><br></div><div>You can increase the buildCacheSize, that may help to trade cpu against memory.</div><div><br></div><div>As for nine, we are approaching a release, cancel/stop have been working for 6+ month.</div><div>We have to see how ui will work with that many builders. For sure it will never hang the master process for 7 seconds, but we might have to work together in order to optimize some parts.</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">Le jeu. 18 févr. 2016 à 18:37, Dan Kegel <<a href="mailto:dank@kegel.com">dank@kegel.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To recap, my site is having response time problems with buildbot 0.8.8<br>
(yeah, it's old).<br>
We have 1356 builders, and used to have 190 gitpollers,<br>
Gitpoller overhead was killing us, and we've slowly been migrating our<br>
git repos to gitlab so we could use webhooks, so we're now down to 72<br>
gitpollers, and buildmaster cpu load is usually low.<br>
Developers are happier than ever with the quick response to checkins,<br>
and with the gitlab merge request -> buildbot try build gateway I threw together<br>
(which finally made buildbot try builds usable by mere mortals!).<br>
<br>
But the waterfall takes 7 seconds to fetch.  Even the /builders page<br>
takes 5 to 6 seconds to fetch, which these days is an eternity.<br>
Doing both at once takes 15 seconds (even on my 4-core Xeon VM).<br>
Developers avoid the waterfall at all costs, and go straight to<br>
individual builder pages.<br>
But they don't have the right builder in their browser completion list all<br>
the time, so they asked me to create a static builders.html page without status.<br>
I now generate that on each reconfigure, and it loads in 5 milliseconds.<br>
This made them a little happier.<br>
I think they'd be happier still if I added static links to the builders from the<br>
gitlab page for each project, so they could avoid the buildbot UI even more,<br>
and stay in happy, beautiful gitlab land as long as possible.<br>
<br>
Hmm, maybe I should assign another few cores to the buildmaster and<br>
see what happens.<br>
<br>
I wonder if my use of sqlite is part of the problem.  Has anyone<br>
with > 1000 builders noticed a radical decrease in time to fetch the<br>
waterfall upon switching from sqlite to mysql?<br>
<br>
And how's nine coming along?   Last I heard, it still lacked a 'cancel<br>
build' button,<br>
which would be an issue here.<br>
- Dan<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@buildbot.net" target="_blank">users@buildbot.net</a><br>
<a href="https://lists.buildbot.net/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.buildbot.net/mailman/listinfo/users</a><br>
</blockquote></div></div></div></div>