[
https://issues.apache.org/jira/browse/CASSANDRA-15766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099605#comment-17099605
]
Yifan Cai commented on CASSANDRA-15766:
---------------------------------------
I have only done a quick glance at the patch.
Essentially, it wraps any expensive computation within the lambda, so in the
case of the log level not permits, no CPU cycles are wasted on computing the
log arguments that are not going to be used. The trade-off is the wrapper,
{{Supplier}}.
Whether it is worthy or not. It depends on how expensive the unnecessary
argument computation is. The computation itself may produce multiple
intermediate objects.
It would be great to have a benchmark to determine the how the lazy logging
helps in the scenarios of 1) no computation, 2) light computation, 3) moderate
computation and 4) heavy computation. So it serves the purpose of guidance on
when to invoke the lazy logging and when to not.
This patch only applies to the {{NoSpamLogger}}. There are other logging
statements that use normal logger in the code base that may have expensive
argument computation. If the lazy impl is proven to have performance benefits,
how about applying to those if any?
The patch does what is wanted in CASSANDRA-15764. I will mark CASSANDRA-15764
as a dup and close once this one is completed.
> NoSpamLogger arguments building objects on hot paths
> ----------------------------------------------------
>
> Key: CASSANDRA-15766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15766
> Project: Cassandra
> Issue Type: Bug
> Components: Observability/Logging
> Reporter: Jon Meredith
> Assignee: Jon Meredith
> Priority: Normal
> Fix For: 4.0-rc
>
>
> NoSpamLogger is used in hot logging paths to prevent logs being overrun. For
> that to be most effective the arguments to the logger need to be cheap to
> construct. During the internode messaging refactor CASSANDRA-15066,
> performance changes to BufferPool for CASSANDRA-14416
> were accidentally reverted in the merge up from 3.11.
> Reviewing other uses since, it looks like there are a few places where the
> arguments require some form of String building.
> org.apache.cassandra.net.InboundSink#accept
> org.apache.cassandra.net.InboundMessageHandler#processCorruptFrame
> org.apache.cassandra.net.InboundMessageHandler.LargeMessage#deserialize
> org.apache.cassandra.net.OutboundConnection#onOverloaded
> org.apache.cassandra.utils.memory.BufferPool.GlobalPool#allocateMoreChunks
> Formatting arguments should either be precomputed, or if expensive they
> should be computed after the decision on whether to noSpamLog has been made.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
