I'm coming late to this discussion, but I'd like to give a big +1 on
this approach. I made this exact change at my last company and it
improved performance dramatically.
glassfish_at_javadesktop.org wrote:
> Hi Carla,
>
> I would like to propose two small additional features regarding the following paragraph dealing with the new asynchronous logger:
>
> "To help improve logging performance, log messages are now written to a queue initially and that queue is emptied to the log file as time permits. The size of the queue is not changable and may fill up if the user has requested log level FINEST and there is a lot of activity on the server. The code does detect if the queue is full and blocks until messages have been written out to the file. Initial tests show that messages can be processed reasonably."
>
> First of all: It is great that finally, all logging will done asynchronously by a dedicated logger thread and no longer effectively serialize processing like with the old implementation. This will greatly improve throughput on large-scale machines for apps that do a lot of logging (for whatever reasons).
>
>
> Proposal #1: Make the size of the BlockingQueue configurable
>
> What will be the constant size of the BlockingQueue? Why not make its size configurable? If not from the admin console, then maybe at least with a JVM system property like the following:
>
> -Dcom.sun.enterprise.server.logging.max_queue_size=8192
>
> If the admin configuring the server instance JVM is able to provide enough memory for this, the number of logging entries in the queue can go up to ehatever still fits into JVM heap memory...
>
>
> Proposal #2: Make the frequency of calls to flush the log file configurable
>
> Allowing to reduce the number of calls to flush() to the logger output stream can also hugely improve logger throughput (even though it will now be done asynchronously).
> If not from the admin console, then maybe also with a system property:
>
> -Dcom.sun.enterprise.server.logging.flush_frequency=10
>
> (a reasonable default still is 1, i.e. flush after every single entry). Setting this to 10 would mean that the log output stream would be flushed only after every tenth log entry, which can help avoid a huge overhead of I/O calls!
>
>
> Many thanks for considering & best regards,
>
> Andreas
>
> --
> Andreas Loew
> Senior Java Architect
> Sun Microsystems (Germany)
> [Message sent by forum member 'al130959' (al130959)]
>
> http://forums.java.net/jive/thread.jspa?messageID=328068
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>