Return-Path: Delivered-To: apmail-qpid-users-archive@www.apache.org Received: (qmail 11667 invoked from network); 14 Dec 2009 15:19:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Dec 2009 15:19:37 -0000 Received: (qmail 21289 invoked by uid 500); 14 Dec 2009 15:19:36 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 21243 invoked by uid 500); 14 Dec 2009 15:19:36 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 21233 invoked by uid 99); 14 Dec 2009 15:19:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Dec 2009 15:19:35 +0000 X-ASF-Spam-Status: No, hits=-10.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of v-cljans@microsoft.com designates 131.107.115.215 as permitted sender) Received: from [131.107.115.215] (HELO smtp.microsoft.com) (131.107.115.215) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Dec 2009 15:19:33 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 14 Dec 2009 07:19:40 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.209]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Mon, 14 Dec 2009 07:19:11 -0800 From: "Cliff Jansen (Interop Systems Inc)" To: "users@qpid.apache.org" CC: "ignacio_ybarra@hotmail.com" Subject: RE: dotnet client 0.10 - performance Thread-Topic: dotnet client 0.10 - performance Thread-Index: AQHKeb0kPD4V5FQfFEGbjnSEWB9Ym5FkrOFA Date: Mon, 14 Dec 2009 15:19:08 +0000 Message-ID: <7BD8F580C04EBD4CB164F4A7E87EF0D113B90BEA@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <151b38ac0912082027oe108d88mc4c316e3c72baae8@mail.gmail.com>,,<151b38ac0912091459v7ddb941dlb52512e76d0b692e@mail.gmail.com>,<151b38ac0912091503x5bad161fka208a66b3b84fd6@mail.gmail.com>,<8cf8f70b0912091508s69ffcd14m58bf2e2302fd07ca@mail.gmail.com>,,<151b38ac0912091757g589ecdbasb39643722b933b19@mail.gmail.com>,,<8cf8f70b0912092137q2bd5a98bs259d3813a0dff5d@mail.gmail.com>, ,<4B212632.2050503@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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]=20 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= (=3D41.6milliseconds/msg) when using this API in synchronous mode, i.e.=20 session.MessageTransfer("hello.exchange", myMessage); = session.Sync(); I am capturing the network traffic between the client and the broker and ca= n 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(_com= mands); ... } 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 messa= ges. Async mode gives me 28K msgs/sec but the nature of this test requires a syn= c after each send. Any help will be appreciated.=20 TIA=20 Ig =20 --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org