Bypass observation in MessageProducerSupport when NOOP registry is configured

[Nephery]

In what version(s) of Spring Integration are you seeing this issue?

6.5.1

Describe the bug

We've been looking into ways to improve our app's messaging throughput in high throughput messaging scenarios.

One thing we've tested out and noticed was that MessageProducerSupport.sendMessage() always creates observability overhead (calling IntegrationObservation.HANDLER) even when ObservationRegistry.NOOP is configured. This seems to result in a performance impact of roughly 15-25% or so in very high throughput messaging scenarios.

To Reproduce

Just run messages as fast as possible through MessageProducerSupport with NOOP observability configured (the default), and watch the throughput.

Expected behavior

When ObservationRegistry.NOOP is configured, observability overhead should be eliminated entirely. The method should detect NOOP registry and bypass observability infrastructure for optimal performance.

One potential solution to this is to add a simple check in MessageProducerSupport.sendMessage():

if (this.observationRegistry.isNoop()) {
    this.messagingTemplate.send(getRequiredOutputChannel(), trackMessageIfAny(message));  // Direct send
} else {
    // existing observability path
}

See this commit for an actual example fix: Nephery@fbb541a

Sample

1. Clone repository: https://github.com/Nephery/spring-integration-noop-observability-perf
2. Follow the setup instructions to install the spring integration fork.
3. Follow these instructions to run the test twice; once with the current spring integration version, and once more with the bypass solution.
4. Compare the test results between the regular and optimized runs, and notice that the optimized run is a bit better.
   • From running this on my personal computer, these are the results I got with roughly a 18% performance increase.

Note: When using this NOOP observability bypass in one of our actual apps, we see similar relative performance gains in these very high throughput scenarios.

[artembilan]

This is good catch!
Thank you!

I see what you mean.
Probably this part has slipped somehow from our attention.
In the AbstractMessageHandler we do have the logic similar to your proposal:

	public void handleMessage(Message<?> message) {
		if (isLoggingEnabled()) {
			this.logger.debug(() -> this + " received message: " + message);
		}
		if (isObserved()) {
			handleWithObservation(message, getObservationRegistry());
		}
		else {
			MetricsCaptor metricsCaptor = getMetricsCaptor();
			if (metricsCaptor != null) {
				handleWithMetrics(message, metricsCaptor);
			}
			else {
				doHandleMessage(message);
			}
		}
	}

Will issue the fix shortly.