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
-~----------~----~----~----~------~----~------~--~---

Reply via email to