diff options
Diffstat (limited to 'doc/v7compatibility.html')
| -rw-r--r-- | doc/v7compatibility.html | 19 |
1 files changed, 17 insertions, 2 deletions
diff --git a/doc/v7compatibility.html b/doc/v7compatibility.html index bf4c0eba..e954ca1d 100644 --- a/doc/v7compatibility.html +++ b/doc/v7compatibility.html @@ -27,9 +27,12 @@ problems to anyone, especially as in v6 this was announced as a missing feature. <h2>"last message repeated n times" Processing</h2> <p>This processing has been optimized and moved to the input side. This results -in far better performance and also de-couples different sources from the same +in usually far better performance and also de-couples different sources +from the same processing. It is now also integrated in to the more generic rate-limiting -processing. The code works almost as before, with two exceptions: +processing. +<h3>User-Noticable Changes</h3> +The code works almost as before, with two exceptions: <ul> <li>The supression amount can be different, as the new algorithm precisely check's a single source, and while that source is being @@ -46,6 +49,18 @@ messages will most probably not be detected. Upgrading the module code is simple, and all rsyslog-provided plugins support the new method, so this should not be a real problem (crafting a solution would result in rather complex code - for a case that most probably would never happen). +<h3>Performance Implications</h3> +<p>In general, the new method enables far faster output procesing. However, it +needs to be noted that the "last message repeated n" processing needs parsed +messages in order to detect duplicated. Consequently, if it is enabled the +parser step cannot be deferred to the main queue processing thread and +thus must be done during input processing. The changes workload distribution +and may have (good or bad) effect on the overall performance. If you have +a very high performance installation, it is suggested to check the performance +profike before deploying the new version. Note: for high-performance +environments it is highly recommended NOT to use "last message repeated n times" +processing but rather the other (more efficient) rate-limiting methods. These +also do NOT require the parsing step to be done during input processing. <p><font size="2">This documentation is part of the <a href="http://www.rsyslog.com/">rsyslog</a> project.<br> |