[
https://issues.apache.org/jira/browse/ARTEMIS-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427049#comment-17427049
]
Gary Tully commented on ARTEMIS-3522:
-------------------------------------
I think the JMS 2.0 api is probably the way to go. The blocking in both cases
seems to be sensible, either for netty threads or for credit. It makes sense to
not have unbounded growth of pending requests on the client, and blocking on
tcp buffers or credit (for core) seems reasonable. I imagine if infinite credit
is available to core, then the tcp push back would block in a similar way to
qpid-jms?
If either implemented a pending queue, it too will need bounds and configurable
blocking or dropping of failing. Timeout would also make some sense (timeout
while in the pending queue having an exact meaning).
I don't think the problem is with the API.
essentially, the question is what to do if some limit is reached, past which
any send would/could block. Below the limit there can never be a guarantee but
above it we need to `do` something.
I can imagine, block, fail, drop could be static options, as could try another
server or compress data (trade cpu for network bandwidth) or rate limit
(increase latency). I think there is lots of potential scope to innovate here.
In essence, knowledge of what is going on with the server would help determine
the best path.
I think the most important thing is to get this sort of tool in play, and then
we can examine the server when clients are blocked and get some insights.
in short, go with JMS 2.0 and that will in some sense be future proofed, even
if it is not currently the best answer for use case 1. It is a great start,
nice work :-)
> Implement performance tools to evaluate throughput and Response Under Load
> performance of Artemis
> -------------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-3522
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3522
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker, JMS
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
>
> There are many performance benchmarks around eg [SoftwareMill
> MqPerf|https://softwaremill.com/mqperf/] that could be used to test
> performance of Artemis in specific scenario, but none is both simple and easy
> to be composed with ad-hoc env setup scripts to perform a wide range of
> different performance tests against the broker.
> This JIRA aim to provide CLI commands that could be used as building blocks
> to perform:
> * all-out throughput tests
> * responsiveness under load tests (with no [coordinated
> omission|http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html])
> ie fixed throughput (per producer) load
> * scalability tests
> The effort of this JIRA should produce CLI commands similar to [Apache Pulsar
> Perf|https://pulsar.apache.org/docs/en/performance-pulsar-perf/] that could
> be composed to create complete performance benchmark pipelines (eg using
> [qDup|https://github.com/Hyperfoil/qDup] and
> [Horreum|https://github.com/Hyperfoil/Horreum] on a CI/CD) or used as-it-is
> by users to quickly check performance of the broker.
> Requirements:
> * support AMQP and Core protocol
> * cross JVMs with microseconds time measurement granularity
> * support parsable output format
> * suitable to perform scale tests
> The last requirement can be achieved both by using MessageListeners and async
> producers available on [JMS
> 2|https://javaee.github.io/jms-spec/pages/JMS20FinalRelease] although both
> [qpid JMS|https://github.com/apache/qpid-jms] and Artemis Core protocols
> blocks the producer caller thread ie the former on
> [jmsConnection::send|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java#L773],
> awaiting Netty threads to unblock it on
> [AmqpFixedProducer::doSend|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpFixedProducer.java#L169],
> while the latter on
> [ClientProducerImpl::sendRegularMessage|https://github.com/apache/activemq-artemis/blob/e364961c8f035613f3ce4e3bdb3430a17efb0ffd/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java#L284-L294].
> This seems odd because [JMS 2's
> CompletionListener|https://docs.oracle.com/javaee/7/api/javax/jms/CompletionListener.html]
> should save any previous send operation to ever block and the user should
> take care (despite being tedious and error-prone) to track the amount of
> in-flight messages and limit it accordly (ie [Reactive Messaging's
> Emitter|https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/emitter/emitter.html#emitter-overflow]
> abstract it with its overflow policies to save blocking the caller thread).
> If JMS 2 both impl cannot be turned into non-blocking then there're just 2
> options:
> # using the blocking variant: it means that scalability tests requires using
> machines with high core numbers
> # using [Reactive
> Messaging|https://github.com/eclipse/microprofile-reactive-messaging], but
> losing the ability to use local transactions (and maybe other JMS features)
> With the first option the number of producers threads can easily be much more
> then the available cores, causing the load generator to benchmark OS (or the
> runtime) ability to context switch threads instead of the broker. That's why
> a non-blocking approach should be preferred.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
