Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
LoggingService log contention (#7492)
Fixes #7364 Context LoggingService.LogComment causes large amounts of contention between unrelated evaluation threads. image Changes Made Reducing lock statements using Interlock.Add as oppose to lock { n+=x; } replace Dictionary with ConcurrentDictionary and remove related locks review locks and remove unnecessary Replacing DataFlow by ConcurrentQueue for event processing Fixing unit tests Testing local run unit testst micro benchmark comparing DataFlow by ConcurrentQueue exp insertion - currently failing on infrastructure - will update Compiled Boost.Hana as described in OOM when generating binlog for boost.hana #3577 - no OOM exception Notes It has surprisingly good perf results. Maybe because I tested it on 24 core machine where lock contention in LoggingService could be a bigger issue. command Duration RAM msbuild /m /bl OrchardCore.sln -25% -4% msbuild /m OrchardCore.sln -13% -3% Microbenchmark comparing DataFlow vs ConcurrentQueue processing 1E6 messages showed ~2 seconds saving (-85%) and about ~250MB allocations less (-92%). I was also considering to use BlockingCollection but for this we do not have support in net3.5 and also I have seen weird huge perf degradation for my use case in net472. Method Mean Allocated DataFlow 2,558,860.6 us 297,286,352 B CocurrentQueue 371,877.9 us 26,304,552 B
- Loading branch information