Ruud H.G. van Tol
rvtol at isolution.nl
Wed May 25 23:55:06 BST 2011
On 2011-05-25 19:33, Daniel Pittman wrote:
> On Wed, May 25, 2011 at 02:10, Ruud H.G. van Tol<rvtol at isolution.nl> wrote:
>> On 2011-05-25 09:19, James Laver wrote:
>>> On 24 May 2011, at 06:31, Daniel Pittman wrote:
>> Anyone here who used Spread recently?
> I made trivial use of it in both testing and production to serve as a
> collector for Apache logs. It was very little trouble, and did the
> job, but was relatively painful to expand the network since it
> required restarts of the service. The Apache log collector handled
> that gracefully, but IIRC you need to specifically support it.
> Performance was reasonable, but then...
> I was using the 3.1 release at the time, though, so I have no idea if
> 4.0 or 4.1 improve on that.
OK, that is presumably fixed in Spread v.4:
"dynamic configuration of sets of daemons without requiring a restart".
>> It is supposed to be faster, lower level, taking< 1% CPU.
> ...CPU load on the network was comparable to the load on ActiveMQ
> systems under similar load. Spread isn't really much different
> otherwise in terms of either speed, or being "lower level" (in either
> the sense of being better for, or worse for, that. ;)
I still expect it to be lighter, because it is rather message-bus than
message-queue. I can see it shine in multi-data-center environments, and
for example be used for data replication.
> If I had to pick a "does as little as possible" low level library, 0mq
> looks like the best available choice, but it provides next to
> *nothing* in terms of scaling; you have a toolkit for messaging and
> get to build out the rest of the routing, scaling, persistence, etc
Interesting indeed. For example the multicast-at-a-distance.
More information about the london.pm