You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Johan Stenberg (JIRA)" <ji...@apache.org> on 2018/07/13 15:21:01 UTC
[jira] [Comment Edited] (QPIDJMS-402) Massive performance
degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543334#comment-16543334 ]
Johan Stenberg edited comment on QPIDJMS-402 at 7/13/18 3:20 PM:
-----------------------------------------------------------------
It looks like the new implementation tries to be too clever. I get the by far best results by stripping down the sync method to this:
{code:java}
public void sync() throws IOException {
try {
int idleCount = 0;
while (true) {
if (isComplete()) {
failOnError();
return;
}
if (idleCount < SPIN_COUNT) {
idleCount++;
} else if (idleCount < YIELD_COUNT) {
Thread.yield();
idleCount++;
} else {
synchronized (this) {
if (isComplete()) {
failOnError();
return;
}
waiting++;
try {
wait();
} finally {
waiting--;
}
}
}
}
} catch (final InterruptedException e) {
Thread.interrupted();
throw IOExceptionSupport.create(e);
}
}
{code}
If idleCount is > YIELD_COUNT it seems much more efficient to directly go into wait instead of doing the parkNanos magic first. Also I strongly believe the "if currentThread.isInterrupted()" check is unnecessary. Removing it gives me another good 8-10% higher throughput.
With this code change I get 45.000 msg/s with v0.34 compared to 32.958 msg/s with v0.33.0. Without that code change I get between 100 and 1000 msg/s with 0.34.0.
was (Author: johan1):
It looks like the new implementation tries to be too clever. The by far best results I by stripping down the sync method to this:
{code:java}
public void sync() throws IOException {
try {
int idleCount = 0;
while (true) {
if (isComplete()) {
failOnError();
return;
}
if (idleCount < SPIN_COUNT) {
idleCount++;
} else if (idleCount < YIELD_COUNT) {
Thread.yield();
idleCount++;
} else {
synchronized (this) {
if (isComplete()) {
failOnError();
return;
}
waiting++;
try {
wait();
} finally {
waiting--;
}
}
}
}
} catch (final InterruptedException e) {
Thread.interrupted();
throw IOExceptionSupport.create(e);
}
}
{code}
If idleCount is > YIELD_COUNT it seems much more efficient to directly go into wait instead of doing the parkNanos magic first. Also I strongly believe the "if currentThread.isInterrupted()" check is unnecessary. Removing it gives me another good 8-10% higher throughput.
With this code change I get 45.000 msg/s with v0.34 compared to 32.958 msg/s with v0.33.0. Without that code change I get between 100 and 1000 msg/s with 0.34.0.
> Massive performance degradation in 0.34.0
> -----------------------------------------
>
> Key: QPIDJMS-402
> URL: https://issues.apache.org/jira/browse/QPIDJMS-402
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.34.0
> Environment: Windows 7x64 + Oracle JDK 8u161x64
> Windows 7x64 + Open JDK 8u171x64
> CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64
> Reporter: Johan Stenberg
> Priority: Critical
> Attachments: QpidJms402_PerfTest.java, image-2018-07-13-16-39-19-707.png, qpidjms402.zip
>
>
> This is a followup issue for [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html]
> I am attaching a simple test case that shows the issue. When I use qpid jms 0.33 I get 2000msg/s send + receive on my local machine. When I switch to 0.34 the message rate drops to 20msg/s.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org