Performance

What affects performance

• Length of log message and arguments list
• Dispatcher configuration
• Format
• Behavior

Sealog performance tests

We use a performance test suite to evaluate Sealog effect on application performance. The suite and results are described in detail here: Performance suite

The performance reports for different releases will be put into Sealog Downloads

Performance recommendations

To find out how each of these factors affect performance in different situations, check performance reports and analyze the result charts. Some of the conclusions are already made in Performance suite section, but if you are going to understand deeply what goes on, you should check the performance reports.

However, there are several simple recommendations, that almost gives you a guarantee that log operations won't noticeably affect your business logic performance in production. So, when you are running in production:

• Don't use 'Info' (and above) messages in a performance critical operations that are frequently called. Check Log levels wiki page.
• Don't allow log levels below 'Info' both in global constraints AND in exceptions.
• Avoid special calculations that are done just to log something. For example: log.Debug("Result=%d", calculateResult()) would of course call 'calculateResults() every time, even if Debug is totally disabled.
• Don't use too many exceptions. So it is always better to pass references to something already calculated in your log arguments lists.
• Don't use heavy formats. For example, "%Date/%Time" verbs are really heavy in terms of logging. So use "%Ns" instead. Sealog uses a pretty fast log format by default, so if you don't change it, it's okay in terms of performance.
• Use asynchronous behavior (Async timer has a minimal effect on performance)

These rules are for production. In development, you can use heavy formats to make log more readable (but more laggy) and do other things that would help debugging if performance is not so critical during development.