You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by clebertsuconic <gi...@git.apache.org> on 2015/06/27 23:55:44 UTC
[GitHub] activemq-artemis pull request: Change on buffer timeout...
GitHub user clebertsuconic opened a pull request:
https://github.com/apache/activemq-artemis/pull/54
Change on buffer timeout...
I had done a lot of tests today, and having 100 nanoseconds for the buffer timeout is a better default for the default installation created through the create command.
I have added some information on when to change as a comment on the xml
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/clebertsuconic/activemq-artemis master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/54.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #54
----
commit 7f6b0191652b0d827ed7376afbdbb09db9ffeabd
Author: Clebert Suconic <cl...@apache.org>
Date: 2015-06-26T17:59:09Z
Change on buffer timeout...
I had done a lot of tests today, and having 100 nanoseconds for the buffer timeout is a better default for the default installation created through the create command.
I have added some information on when to change as a comment on the xml
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] activemq-artemis pull request: Change on buffer timeout...
Posted by clebertsuconic <gi...@git.apache.org>.
Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/54#issuecomment-116672776
Get artemis/master, build it:
go to artemis-distribution/target/apache-artemis-1.0.1-SNAPSHOT-bin/apache-artemis-1.0.1-SNAPSHOT/bin
```sh
./artemis create /tmp/myserver --user me --password me --allow-anonymous
/tmp/myserver/bin/artemis-service start
/tmp/myserver/bin/artemis producer
```
```
macbookCleb-2:bin clebertsuconic$ /tmp/myserver/bin/artemis producer
Producer ActiveMQQueue[TEST], thread=0 Started to calculate elapsed time ...
Producer ActiveMQQueue[TEST], thread=0 Produced: 1000 messages
Producer ActiveMQQueue[TEST], thread=0 Elapsed time in second : 0 s
Producer ActiveMQQueue[TEST], thread=0 Elapsed time in milli second : 695 milli seconds
```
You can do the same at ActiveMQ5. Build the ActiveMQ5 master, start the broker, and run activemq producer..
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] activemq-artemis pull request: Change on buffer timeout...
Posted by clebertsuconic <gi...@git.apache.org>.
Github user clebertsuconic closed the pull request at:
https://github.com/apache/activemq-artemis/pull/54
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] activemq-artemis pull request: Change on buffer timeout...
Posted by fredrikjonson <gi...@git.apache.org>.
Github user fredrikjonson commented on the pull request:
https://github.com/apache/activemq-artemis/pull/54#issuecomment-116262734
Clebert,
First, perhaps you'll find the following phrasing clearer: "Timeout, in nanoseconds, after which all journal buffer data is written to disk, regardless of amount of buffered data. Increasing this value can improve message throughput at the cost increased latency." The phrasing was inspired by the current user manual, http://activemq.apache.org/artemis/docs/1.0.0/persistence.html
Second, I'm surprised by the proposed new value, 100 ns. I'm certain I must have misunderstood either the unit (ns) or the current documentation of journal-buffer-timeout. The documentation states that the attributes current "default for NIO is 3333333 nanoseconds - 300 times per second, default for AIO is 500000 nanoseconds - ie. 2000 times per second." Is your intent really to reduce this value several 1000 times, from 3333333 ns to 100 ns? Wouldn't that increase the worst case IOPS requirement on the disk system from 2000 IOPS to 10000000(!) IOPS?
Third, wouldn't it be better to change the default values in the source and let that change be reflected by an update of the user manual (there are AFAIU two distinct values BTW, depending on AOI or NIO), rather than changing a generated default configuration and thus letting the default configuration diverge from the default value in the source code and the manual?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] activemq-artemis pull request: Change on buffer timeout...
Posted by fredrikjonson <gi...@git.apache.org>.
Github user fredrikjonson commented on the pull request:
https://github.com/apache/activemq-artemis/pull/54#issuecomment-116482583
I'm curious, could you share how you are running the p/c-tool to compare between amq5 and aremis? And how would one determine where the cause of the observed performance difference is located?
It seems to me that the current default values for journal-buffer-timeout would theoretically allow a worst case latency for lingering packages of 3,3 ms on NIO, and 0.5 ms on AIO. (Right?) That is not bad at all, and quite far away from the 1-2 seconds you're reporting (per 1000 msg). Especially for a throughput test where the transfer pattern - many messages at once with little to no delay between them - really should be a perfect match for buffered disk IO.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] activemq-artemis pull request: Change on buffer timeout...
Posted by clebertsuconic <gi...@git.apache.org>.
Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/54#issuecomment-116153298
if someone with native english could please review my wording on broker.xml for this PR?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] activemq-artemis pull request: Change on buffer timeout...
Posted by clebertsuconic <gi...@git.apache.org>.
Github user clebertsuconic commented on the pull request:
https://github.com/apache/activemq-artemis/pull/54#issuecomment-116432004
The issue I have is the following:
I have recently imported the new Producer and Consumer tool from activeMQ5 into Artemis.
When you run the producer, the system is taking 1 or 2 seconds to finish sending 1000 messages, while it takes only a few milliseconds on ActiveMQ5.
I thought this could be a better setting for development and quick comparisons... while it would be best for production systems.
The best would be really to make the system to test the best value on the create of the server, or having a more adaptative logic to increase or decrease these timeouts during the life of the server. (To be discussed).
I will change this PR to make a test of the best value for now... will keep it open so don't merge it yet please.
(I will look for a btter logic tomorrow)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---