[Spread-users] mod_log_spread: Multiple daemons versus single daemon

Christian Robottom Reis kiko at async.com.br
Thu Sep 13 21:33:46 EDT 2001


On Thu, 13 Sep 2001, Theo Schlossnagle wrote:

> Remember, most OSs don't show you a good representation of time waiting
> for I/O.  So, if 30% CPU usage better or worse that the invisible or
> poorly represented I/O usage?  I don't know the answer, but at least
> keep the question in mind :-)

I see. So the measurement could show that we're hitting higher than we are
- it could just be that we're just waiting for the multicasts to happen.
That sounds reasonable. So how _could_ I measure accurately?

> > machines can take the traffic, shouldn't avoiding the multicasting be
> > better? In other words, are we stressing the local loop between server
> > and local daemon, without making things any lighter on the network at
> > all?
>
> Multicasting should be very very cheap?  What OS are you running?

Linux-2.2. But my question is more like: why spend the time connecting
locally and then having the local spread forward messages if we could cut
that part of the loop and communicate directly? If we had many consumers,
I agree, it's required, but since I only run one spreadlogd, where are the
benefits?

I can see one, which is reduced latency for apache, which can be free to
talk to a local daemon and process other calls (faster, sure) and leave
the daemon to sort out sending messages around. I can see also that spread
can store messages and send them in larger blocks around, thus making it
more efficient (but possibly breaking the time-sequentiality of logs?
hmmm) but that seems minor.

Are there others?

> You should really post the message to the mls mailing list for that kind
> of response :-)
>
> http://lists.backhand.org/mailman/listinfo/mls-users

/me is a dork and should read webpages with his eyes open

Thanks Theo. :)

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL






More information about the Spread-users mailing list