activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Gomes (JIRA)" <>
Subject [jira] Updated: (AMQNET-109) NMS does not use TcpNoDelay which results in poor performance compared to Java
Date Tue, 02 Sep 2008 21:05:52 GMT


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:
>             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.

View raw message