Burton, I would be interested to hear more about the externalization changes. We had this discussion and patch from Ole Dalgaard back in March.
http://marc.theaimsgroup.com/?t=101713445200004&r=1&w=2 What are the chances that these changes will be backward compatible to previous versions of log4j? I would also like to learn more about UDP. How do I set something like that up? I think we have talked about creating some UDP specific appenders in the past. -Mark > -----Original Message----- > From: Leathers, Burton [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 10:36 AM > To: 'Log4J Developers List' > Subject: RE: Socket Performance? > > > The data Mark reports is very much in line with what we have > seen here at > Cognos. Of course, we can introduce a lot of variability by > changing OS, > hardware and so forth but the data remain in the same > ballpark. We have been > pursuing two approaches to improving the number. > > The one we have tested is the use of UDP instead of TCP. This is not a > panacea. It does give a significant increase in throughput > but we have had > some problems with message loss. This is a known quality (!?!) of UDP. > Various tweaks have served to reduce the loss rate but we > have not licked > the problem. I have not at all given up because I think our > stress test > program in which the message senders and receivers reside in > the same JVM > results in overruns due to thread scheduling factors. A more > "natural" load > generation would not hose the server in the same way and so > it should be > able to handle the inputs in a production environment -- or so I hope. > > We are also looking at using externalization rather than > serialization. This > has a number of significant impacts. It allows the > transmission of objects > rather than rendered objects (a good things for us). It is cheaper to > externalize an object than to serialize or render it. The > datagrams are the > same size as or smaller than serialized datagrams -- > especially if, like me, > you serialize your message objects instead of sending > rendered objects. I > should know in a few days how much we save by this method. > > Hope this helps, > > Burton > > > > -----Original Message----- > From: Mark Womack [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 12:50 PM > To: Log4j-Dev (E-mail) > Subject: Socket Performance? > > > It just seems that one thing leads to another...I was looking > through my > Receiver implementation and decided to run some ad-hoc > performance tests. I > configured 3 processes on my machine: 1 with a SocketReceiver (matches > SocketAppender), 2 with SocketAppenders. The SocketAppenders > both connected > to the SocketReceiver, and all processes also had ConsoleAppender > configured. > > I had the SocketAppender processes run simultaneously for 20 > seconds. The > SocketReceiver processed all of the logging events sent across the > SocketAppender/SocketReceiver connection. I tried various > permutations in > the implementation (buffered streams input and output, a > event queue in the > receiver, etc). The best performance I ever tracked (mind > you, this was > ad-hoc) ~220 events/second for each SocketAppender process. > This means that > with both processes running, the SocketReceiver was > processing about ~440 > events/second. > > I know that there are a lot of variables that will affect > this performance, > and I don't have anything to compare this to. Does this > perfomance compare > to other people's experience sending logging events across > sockets? Do we > have some code we use as a benchmark/test? We should. > > And looking at this performance stuff leads me to the > previous discussion > about optimizing the serialization of the LoggingEvent > object...I think the > most gains will be made with that work. > > -Mark > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
