[muscle] Re: zlib encoding and muscled

  • From: "Jeremy Friesner" <jaf@xxxxxxxxxxxx>
  • To: Wilson Yeung <wilson@xxxxxxxxx>
  • Date: Sun, 06 Jun 2004 23:26:30 PDT (-0700)

Hi Wilson,

> I'm able to sustain about 20,000 messages per second between a dual 
> processor PIII 600 and a 12" Powerbook.

That's a good data point to know.  :^)
> The receiving clients don't do anything with the incoming messages.  
> They just take the incoming message off the queue and throw it away 
> (well, it's a MessageRef object, so I expect that not doing anything 
> means eventual release/deallocation).  Yet I see the memory usage on 
> the receiving processes grow from ~20MB to ~125MB over time.  I don't 
> think memory fragmentation should be an issue as you're using 
> object/memory pools, and I'm not doing any heap allocation, so I'm a 
> little surprised that memory usage grows much at all. 

I'm a little surprised too.   If you can post or send me the test code, I might
be able to reproduce the behaviour here, and figure out why that is happening.

> Does it have 
> something to do with the incoming message queue being jammed with data=3F 

It might be, if the receiving process is processing Messages more
slowly than they are being received... but I wouldn't expect that if
the Messages are just being immediately thrown away.

Alternatively, if the process whose memory size is growing is
also sending a lot of Messages back, it is quite possible that Messages
are being added to its outgoing Message queue faster than the
network connection can drain the queue; that would definitely 
cause memory usage to grow.

> Are the object pools being resized=3F  If that's the case, is there a 
> recommended method to restrict the size of the object pools=3F

The ObjectPools have a fixed maximum size; if more objects
than that size are created and then released, the "extra" objects
will be deleted because the pool is full.

One thing you might try is to define the compiler flag
DISABLE=5FOBJECT=5FPOOLING (either in the Makefile, or
by uncommenting line 14 of ObjectPool.h) and see if that
has any effect on the memory-usage behaviour of the program(s).
It might just be that a lot of objects are being cached for later 
re-use (although 125MB worth seems very excessive for that!)

> I'm planning to include the muscle system in a pretty mixed 
> environment, including possibly some C# clients, so I'm thinking of 
> writing a C# client API modeled after the Java client API.  Is there 
> interest by anyone else in such a thing=3F

I don't know, but if you write such an API I'd be happy to include
it in the muscle distribution, for completeness :^)


Other related posts: