On Wednesday 10 July 2002 20:51, Ceki Gülcü wrote: > 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.
Well, very much more depending on the physical transport. Assuming that high performance networks are the in question here; On a 100BaseT network, experience tells me that IP packets will not go faster with less payload, i.e if the traditional 1500 bytes IP packets are used on the network, packets of that size will not be significantly slower that 15 bytes packets, but the char/sec throughput a lot higher. > 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? > When 440 messages transit per second, what is the CPU load? Assuming a > single machine, it is likely to approach 100%. However, will this be the > case when using multiple machines? 400 messages per second sounds a lot like the peek of RMI. No matter what you do, RMI will not go much further beyond this point, mainly due to network packet speed, as described above. This has been discussed extensively on RMI-Users mailing list. The SocketAppender (or a derivative) can leave RMI far behind, by implementing its own marshalling protocol, and not have a command/response requirement. Whether an UDP or a TCP approach is taken, doesn't really matter. What matters is the reduction of number of IP packets on the network, which means that logging events should typically be packed together, for improved performance. The SocketAppender could have a tuning parameter for how many characters to hold in the buffer before a flush is issued. Combine that with a "time threshold", saying that characters should not stay longer than 200ms in the buffer, and I think you have a pretty powerful system. Niclas -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
