Mailing List Archive

On Wednesday, August 15, 2001, at 05:02 PM, Sean Chittenden wrote:
> Hey, this is aimed primarily at Theo, but I was wondering if
> you've thought about making the moderator process a standalone daemon
> that would monitor/broadcast the state/health/load of a system.
> Thoughts? -sc

I think that is a great plan. We have talked about that here a few
time. One of the biggest problems is that the "serverstats" contains a
few things that are quite Apache-centric. The number of available
servers and total servers is fairly specific to Apache. They can be
left as zero's. More complicated however, are the number of requests
and average turnaround time on requests that are updated by the
webserver itself.

It is an interesting idea and it wouldn't be too hard to implement, but
I have many projects on the docket. If you or anyone else are
interested in implementing this, I would be more than happy to roll it
into the distribution. My idea was to have the daemon build a shared
memory segment (just like it does now) and write the shm id to a file.
mod_backhand will start up, read that file, and attach to the
appropriate shm segment.

This allows for many cool possibilities. the most obvious is the
extension on the type of web server than can be workhorse in a
mod_backhand cluster. More elusive, perhaps, is the extension of
services like Linux's kernel ipvs support to use the shm segment for
resource information and adapt the mod_backhand's candidacy system to
work with it.

Neat possibilities.

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7

> > Hey, this is aimed primarily at Theo, but I was wondering if
> > you've thought about making the moderator process a standalone daemon
> > that would monitor/broadcast the state/health/load of a system.
> > Thoughts? -sc
>
> I think that is a great plan. We have talked about that here a few
> time. One of the biggest problems is that the "serverstats" contains a
> few things that are quite Apache-centric. The number of available
> servers and total servers is fairly specific to Apache. They can be
> left as zero's. More complicated however, are the number of requests
> and average turnaround time on requests that are updated by the
> webserver itself.

Thinking about modularity, would it be possible to do something
like the following (pardon the perl code, I think it's easy to grok for
this app):

my $server_stats = {
backhand => {
mem_usage => '256MB',
ariba => '234234',
etc...
},
apache => {
avg_page_time => '0.003s',
numb_req => '23423',
etc....
},
};

Where backhand and apache are apart of a multi-dimensional array
internally (limiting the number of primary stat collection devices to a
byte).

> It is an interesting idea and it wouldn't be too hard to implement, but
> I have many projects on the docket. If you or anyone else are
> interested in implementing this, I would be more than happy to roll it
> into the distribution. My idea was to have the daemon build a shared
> memory segment (just like it does now) and write the shm id to a file.

Or possibly from a socket if the shmid needs to change...

> mod_backhand will start up, read that file, and attach to the
> appropriate shm segment.
>
> This allows for many cool possibilities. the most obvious is the
> extension on the type of web server than can be workhorse in a
> mod_backhand cluster. More elusive, perhaps, is the extension of
> services like Linux's kernel ipvs support to use the shm segment for
> resource information and adapt the mod_backhand's candidacy system to
> work with it.

Actually, I was thinking about incorporating it into a nifty
distributed ruby processing environment. Marshall a ruby object, send
it to the fastest/best server, then have the ruby object executed on the
remote box. Given that marshall/unmarshall are built into ruby it seems
like this could be a really cool way to handle independent data
processing requests. ;~)

> Neat possibilities.

Very. I'll have to see if I can get any time here this weekend
to work on this, but don't hold your breath: I'm notorious for thinking
I'll be able to do something on the weekend and then having my weekend
disappear before I realize its Tuesday of the next week. ;~) -sc

--
Sean Chittenden