Major Description
There are scenarios where logging (even asynchronous logging) can become a performance bottleneck for the application; specifically, during a burst of activity the application may produce log events faster than the appender can consume them. If such a burst continues long enough, the queue that is used to pass log events from the producing (application) thread to the consuming (appender) thread may fill up.
Note that the queues used by AsyncLoggers and by AsyncAppenders are both bounded queues. Once this queue is full, the producer can only add log events at the same speed that the appender can consume them. So from that point the application becomes IO-bound.
The correct size of the queue is both application and environment dependent. At what rate do events arrive during a burst? How long does a burst continue? How fast can the consumer take events off the queue?
In order to be able to tune the queue size, users need a way to sample the queue usage: at the time of the snapshot, how many events are in the queue waiting to be processed? (In concurrent scenarios the answer to this question is pretty much always out of date, but it is still useful to help determine a good queue size.)
