> These figures are somewhat meaningless. The throughput of the socket
> appender depends on the network connection, the CPU on the client and
> server side, as well as the length of the messages sent. Sending
> messages 5 character long will take significantly less time 
> than sending
> messages 5KB long.

I completely agree, but I was just checking if what I was seeing was
completely out of line.  It appears that it is not, though individual
relates may vary greatly depending on environment.

> These parameters must fixed and their influence studied carefully. I
> would test the results with message lengths of 10, 100 and 1000
> characters. The real problem is the identification of the bottleneck.
> Is it the CPU or the network bandwidth?

I think some kind of performance measuring code would be helpful here.  I
think will put together something for my contribution directory.  Then we
could gather data from folks, capturing some idea about their setup.

I guess the point I am trying to make is that if there is anything we can do
in the log4j code to increase this throughput, we should look into doing it.
Using externalizable is one way, though it carries an incompatibility risk.
Maybe creating different kinds of remote appenders (like UDP) is another
way.  But, we need to capture some kind of base line data to understand if
the changes are effective.  I got led in this direction while trying to
determine if my Receiver design was adding any significant overhead to the
socket transmission.  That's all.

-Mark

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to