[
https://issues.apache.org/jira/browse/ARTEMIS-3522?focusedWorklogId=730766&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-730766
]
ASF GitHub Bot logged work on ARTEMIS-3522:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 22/Feb/22 10:39
Start Date: 22/Feb/22 10:39
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3857:
URL: https://github.com/apache/activemq-artemis/pull/3857#discussion_r811805654
##########
File path: LICENSE
##########
@@ -208,3 +208,6 @@
This file is in the public domain. For more information see:
activemq-commons/src/main/java/org/apache/activemq/utils/Base64.java
+
+This product bundles HdrHistogram, which is available under a
+"2-clause BSD" license. For details, see
https://github.com/HdrHistogram/HdrHistogram/blob/master/LICENSE.txt.
Review comment:
This needs changed for a couple reasons.
This is almost certainly the wrong LICENSE file. This is for the source
release. You prsumably are depending on a binary and so, if it is distributed,
this would go in the binary archives LICENSE file, at
_artemis-distribution/src/main/resources/licenses/bin/LICENSE_.
The licence itself needs to be included in the file, or in another file
within the repo and referenced to (since the URL contents could change, e.g to
a different licence, or just go away, e.g branch change without using the
rename tool). Youll see lots of examples of the latter in the other file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 730766)
Time Spent: 1h 50m (was: 1h 40m)
> 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
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> 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.20.1#820001)
