SmartInspect 3.0: Asynchronous Logging

One of my favorite new features of the upcoming SmartInspect 3.0 is support for asynchronous logging. What asynchronous logging basically does is to move the protocol/connection related operations (such as writing a packet or doing a reconnect attempt) from your application thread into a dedicated logging thread.

One thing to note is that we did not add asynchronous logging to SmartInspect with the main intent of improving the logging performance. We rather added it to reduce the possibility of blocking the application while doing an I/O operation. I/O operations are usually very expensive and can thus be a problematic part of your logging layer, especially in performance-critical applications.

Asynchronous logging can operate in one of two different modes: throttle and non-throttle. The underlying implementation of the asynchronous protocol mode uses a queue to pass packets and connect/disconnect instructions from your application thread to the logging thread. This queue is size-limited (the size can be configured with a protocol option) and the different modes specify what to do when this queue reaches its maximum size. In throttle mode, a protocol waits until there’s room in the queue to add the next packet. In non-throttle mode, a protocol doesn’t wait for the logging thread but rather discards old packets from the queue in order to not block the application.

Which mode is best-suited for your application greatly depends on your specific needs. Basically, if you need a guarantee that all packets are really logged and none is discarded, you should use the throttle mode. On the other hand, if performance is more important and loosing log packets is acceptable, you should go with the non-throttle mode.

Asynchronous logging is especially useful for logging over a network via TCP/IP. When a network problem occurs while you are logging over TCP/IP, the application usually blocks until a timeout is reached. If you are using asynchronous logging, the timeout doesn’t affect your application at all. The separate logging thread and not your application is doing the waiting for the remote machine.