If I understand right, simply serving the auto-refresh requests is substantial? At least for the main page, a reverse in accelerator mode could turn that into a constant load.
[I'd offer to help, but I don't know what kind of technology we're talking about, here.] -scott On Tue, Jul 14, 2009 at 2:25 PM, Evan Martin<e...@chromium.org> wrote: > > On Tue, Jul 14, 2009 at 2:18 PM, Nicolas Sylvain<nsylv...@chromium.org> wrote: >> The underlying problem with buildbot is the database format, which is just >> hundred of >> thousand of files on the harddrive, with no "seek" capability, and the fact >> that the >> webserver itself is single threaded. >> We currently have 63 slaves on our main waterfall. I think this is too >> many for what >> buildbot can really support. We would ideally need to split it. > > Can we get upstream buildbot devs involved in this discussion? It > seems they ought to be able to scale better than they have. > > It seems to me a caching layer that only ever hit the "backend" every > ten seconds would allow it ten seconds to grind through its > computations, which should be more than sufficient, without any extra > splitting up required. That is, we should (a) fix the proxy and (b) > make every use the proxy. > >> Q3: What kind of auto-refresh do we need? >> We used to be at 60 secs for a long time, and I changed it a couple of >> weeks ago to 90 secs. >> No one complained, so I guess this is good. Should we go even higher than >> that? > > I personally hate auto-refresh. We should make it opt-in since I > doubt most users need it and it adds load. I expect many people > (myself included) leave the buildbot page open in a background tab and > have it continually refreshing despite not looking at it. > > (My other common use case: the tree is red, I start scrolling down to > see what's gone wrong, and then the page refreshes out from under me > and I lose where I was looking.) > >> - Get a better machine. It's already running on a dedicated dual quad core >> nehalem server >> with 24gb of RAM and 15k rpm drives. > > This is absurdly powerful! It should have all the data necessary to > generate the page in RAM already, no need for even touching the disks > (?). > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---