Re: dotnet client 0.10 - Sync() and Close()

[Carl Trieloff <cc...@redhat.com>]

Coping Dev list.

Carl.


Ignacio Ybarra wrote:
> correction - TotalMilliseconds returns as a double so you will need to cast it:
> from:	(!) elapsed = DateTime.Now.Subtract(start).Milliseconds;to: elapsed = (int) DateTime.Now.Subtract(start).TotalMilliseconds;
> cheers
> ig
>
>   
>> From: ignacio_ybarra@hotmail.com
>> To: users@qpid.apache.org
>> Subject: dotnet client 0.10 - Sync() and Close()
>> Date: Thu, 10 Dec 2009 13:20:03 +0000
>>
>>
>> Hi - any chance someone could modify 
>>
>> http://svn.apache.org/viewvc/qpid/trunk/qpid/dotnet/client-010/client/transport/Session.cs
>>
>> lines 373 and 486 as per below:
>>
>> from:	(!) elapsed = DateTime.Now.Subtract(start).Milliseconds;
>>
>> to: 	elapsed = DateTime.Now.Subtract(start).TotalMilliseconds;
>>
>> The reason for this request is that TimeSpan.Milliseconds will always return a value between [-999,999].
>>
>> This means the condition (elapsed < timeout) in lines 368 and 483 will always be true with the default 
>>
>>         private const long _timeout = 600000;
>>
>> (or any timeout values >= 1000) which can lead to an infinite loop when calling Session.Sync() and Session.Close().
>>
>> Many thanks
>>
>> Ig
>>
>>  		 	   		  
>>     
>  		 	   		  
>   

RE: dotnet client 0.10 - performance

["Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>]

Hi Ignacio,

If you are using durable messages, your test may be mainly measuring
the speed of the broker's message store on your hardware.

I have very little knowledge of the dotnet client, but using both the
qpid/wcf and qpid/cpp clients with a Linux broker give the following
numbers for 100 byte messages (using WcfPerftest and perftest
respectively):

  async:              66k msg/sec
  sync (not durable): 2.8k msg/sec
  sync (durable):     100 msg/sec

Which gives a similar amount of change between the first and third as
you are seeing.

My hardware consists of a couple of inexpensive desktops running
Windows (Client) and Fedora (broker) connected by a lowly 100Mbit/s
Ethernet switch.  The Linux broker's message store is in its default
configuration and "powered" by a single desktop 7200RPM drive.  I have
no doubt that with a little tuning and fancier storage hardware, the
durable number can be made to approach the non durable synchronous
number.

Cliff

-----Original Message-----
From: Ignacio Ybarra [mailto:ignacio_ybarra@hotmail.com] 
Sent: Thursday, December 10, 2009 9:20 AM
To: users@qpid.apache.org
Subject: dotnet client 0.10 - performance


Hi - has anybody benchmarked the dotnet client 0.10?
I am finding that a single publisher thread only goes as fast as 24 msg/sec (=41.6milliseconds/msg) when using this API in synchronous mode, i.e. 
            session.MessageTransfer("hello.exchange", myMessage);            session.Sync();
I am capturing the network traffic between the client and the broker and can see the message going to the broker (RHEL MRG) and coming back within ~2.1ms (implying a broker limitation of around 476msg/sec). The remaining time seems to be spent in code, somewhere between
	org.apache.qpid.transport.network.IoReceiver.Go()
	and
	org.apache.qpid.transport.Session.Complete(...) {... Monitor.PulseAll(_commands); ... }
which signals Session.Sync(...) { ... Monitor.Wait(_commands, (int)(timeout - elapsed)); ... } on the same class.
The payload is insignificant in this case - we are testing with small messages.
Async mode gives me 28K msgs/sec but the nature of this test requires a sync after each send.
Any help will be appreciated. 
TIA 
Ig


 		 	   		  

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

dotnet client 0.10 - performance

[Ignacio Ybarra <ig...@hotmail.com>]

Hi - has anybody benchmarked the dotnet client 0.10?
I am finding that a single publisher thread only goes as fast as 24 msg/sec (=41.6milliseconds/msg) when using this API in synchronous mode, i.e. 
            session.MessageTransfer("hello.exchange", myMessage);            session.Sync();
I am capturing the network traffic between the client and the broker and can see the message going to the broker (RHEL MRG) and coming back within ~2.1ms (implying a broker limitation of around 476msg/sec). The remaining time seems to be spent in code, somewhere between
	org.apache.qpid.transport.network.IoReceiver.Go()
	and
	org.apache.qpid.transport.Session.Complete(...) {... Monitor.PulseAll(_commands); ... }
which signals Session.Sync(...) { ... Monitor.Wait(_commands, (int)(timeout - elapsed)); ... } on the same class.
The payload is insignificant in this case - we are testing with small messages.
Async mode gives me 28K msgs/sec but the nature of this test requires a sync after each send.
Any help will be appreciated. 
TIA 
Ig