You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Stefan Gmeiner (JIRA)" <ji...@apache.org> on 2008/08/27 16:37:52 UTC
[jira] Created: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
NMS does not use TcpNoDelay which results in poor performance compared to Java
------------------------------------------------------------------------------
Key: AMQNET-109
URL: https://issues.apache.org/activemq/browse/AMQNET-109
Project: ActiveMQ .Net
Issue Type: Improvement
Components: ActiveMQ Client
Environment: ActiveMQ 5.1 with NMS trunk revison 688066
Reporter: Stefan Gmeiner
Assignee: James Strachan
Attachments: NMS-TcpNoDelayEnabled.patch
We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Gomes updated AMQNET-109:
-----------------------------
Assignee: Jim Gomes (was: James Strachan)
Fix Version/s: 1.0
Affects Version/s: 1.0
Due Date: 03/Sep/08
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: Jim Gomes
> Fix For: 1.0
>
> Attachments: NMS-TcpNoDelayEnabled.patch
>
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Stefan Gmeiner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Gmeiner updated AMQNET-109:
----------------------------------
Attachment: NMS-TcpNoDelayEnabled.patch
Sorry, I overseen the license option on the first upload.
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: James Strachan
> Attachments: NMS-TcpNoDelayEnabled.patch, NMS-TcpNoDelayEnabled.patch
>
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work logged: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#action_36775 ]
Jim Gomes logged work on AMQNET-109:
------------------------------------
Author: Jim Gomes
Created on: 02/Sep/08 09:27 AM
Start Date: 02/Sep/08 09:27 AM
Worklog Time Spent: 6 hours
Issue Time Tracking
-------------------
Remaining Estimate: 2 hours
Time Spent: 6 hours
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: Jim Gomes
> Fix For: 1.0
>
> Attachments: NMS-TcpNoDelayEnabled.patch
>
> Time Spent: 6 hours
> Remaining Estimate: 2 hours
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on AMQNET-109 started by Jim Gomes.
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: Jim Gomes
> Fix For: 1.0
>
> Attachments: NMS-TcpNoDelayEnabled.patch
>
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Gomes resolved AMQNET-109.
------------------------------
Resolution: Fixed
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: Jim Gomes
> Fix For: 1.0
>
> Attachments: NMS-TcpNoDelayEnabled.patch, nmsspeedtest.cs
>
> Time Spent: 6 hours
> Remaining Estimate: 2 hours
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Stefan Gmeiner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Gmeiner updated AMQNET-109:
----------------------------------
Attachment: (was: NMS-TcpNoDelayEnabled.patch)
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: James Strachan
> Attachments: NMS-TcpNoDelayEnabled.patch
>
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work logged: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#action_36776 ]
Jim Gomes logged work on AMQNET-109:
------------------------------------
Author: Jim Gomes
Created on: 02/Sep/08 02:06 PM
Start Date: 02/Sep/08 02:06 PM
Worklog Time Spent: 2 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 2 hours)
Time Spent: 8 hours (was: 6 hours)
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: Jim Gomes
> Fix For: 1.0
>
> Attachments: NMS-TcpNoDelayEnabled.patch, nmsspeedtest.cs
>
> Time Spent: 8 hours
> Remaining Estimate: 0 minutes
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQNET-109) NMS does not use TcpNoDelay which
results in poor performance compared to Java
Posted by "Jim Gomes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQNET-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Gomes updated AMQNET-109:
-----------------------------
Attachment: nmsspeedtest.cs
Speed test framework that compares the difference between TcpNoDelayEnabled. The source code is freely available, but the ASF license is intentionally not granted, since this code is not intended for inclusion in any ASF product.
> NMS does not use TcpNoDelay which results in poor performance compared to Java
> ------------------------------------------------------------------------------
>
> Key: AMQNET-109
> URL: https://issues.apache.org/activemq/browse/AMQNET-109
> Project: ActiveMQ .Net
> Issue Type: Improvement
> Components: ActiveMQ Client
> Affects Versions: 1.0
> Environment: ActiveMQ 5.1 with NMS trunk revison 688066
> Reporter: Stefan Gmeiner
> Assignee: Jim Gomes
> Fix For: 1.0
>
> Attachments: NMS-TcpNoDelayEnabled.patch, nmsspeedtest.cs
>
> Time Spent: 6 hours
> Remaining Estimate: 2 hours
>
> We are evaluating the NMS-API to connect a C# app to our ActiveMQ broker. For this we wrote a simple client which sends a request and waits for a reply (Client --> Broker --> Server --> Broker --> Client). The client/server C#-app runs in a single process with two different connections to the broker which resides on a different pc on the network.
> This scenario takes about 200ms for each message transfered by the C#-API and less than 20ms by the Java-API although both do the same thing.
> After looking through the code I found out that the NMS client does not use the TcpNoDelay-Option during the wire negoation. I changed the code so that this option will be negotiated with the broker and set on the underlying socket and now I have apperently the same performance as with Java. I attached the code change as patch to the current trunk version of the .NET-client.
> We would be happy if someone could check the patch and give some feedback.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.