From users-return-4232-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Wed Jun 8 13:05:51 2011 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 75D9D415E for ; Wed, 8 Jun 2011 13:05:51 +0000 (UTC) Received: (qmail 36518 invoked by uid 500); 8 Jun 2011 13:05:51 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 36490 invoked by uid 500); 8 Jun 2011 13:05:51 -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 36482 invoked by uid 99); 8 Jun 2011 13:05:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Jun 2011 13:05:51 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cctrieloff@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Jun 2011 13:05:44 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p58D5NPT004196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Jun 2011 09:05:23 -0400 Received: from [10.16.19.73] (dhcp-100-19-73.bos.redhat.com [10.16.19.73]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p58D5NEP025871 for ; Wed, 8 Jun 2011 09:05:23 -0400 Message-ID: <4DEF7263.7020505@redhat.com> Date: Wed, 08 Jun 2011 09:00:19 -0400 From: Carl Trieloff Reply-To: cctrieloff@redhat.com Organization: Red Hat User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Recommended API for Python? References: <4DE921C0.2000509@princeton.com> <4DE92EB9.6050806@redhat.com> <4DEEBBFA.30708@princeton.com> In-Reply-To: <4DEEBBFA.30708@princeton.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 On 06/07/2011 08:02 PM, Anthony Foglia wrote: > On 06/03/2011 02:58 PM, Ted Ross wrote: >> API (3) is a literal/mechanical binding of the C++ API in Python. Our >> intent is to provide a thin Python wrapper around this binding that is a >> drop-in replacement for API(2). The benefits of this API are that all of >> the features of the C++ API are made available via Python (RDMA >> transport, full SASL auth/security support, future features, etc.). I >> would also expect the wrapped API to perform better than the pure-Python >> API. I find it surprising that you're not seeing this. > > Well, I've repeated my timings numerous times, and the results seem to > be that the on average the SWIG library performs slightly faster that > the Python library. But the variance is humongous. I'm only timing > the consumer side, so maybe the performance will be better on the > sender. But for my last 5 runs of 20000 messages, I'm getting rates of > 1600 +/- 20 for the pure python api, and 1320 +/- 844 for the swig > version. And these are the typical results, comparable times on > average, with huge variance for the swig api. > > One major difference though is that the python version is spending > nearly all the time in user space, while the swig version is only > spending a tenth in user, and 5% in system space. I assume the rest > is waiting for the network, but (a) I'm trying to acknowledge the > messages asynchronously, and (b) it would be quite the coincidence if > the Python client is getting maxed at exactly the same rate as the C++ > broker. async transfer is the largest impact, not acknowledgement. > > Either of these times are way less than the 50,000 transfers/sec > qpid-perftest tells me the broker is capable of. (34,000 publish, > 26,000 subscribe). > > I've attached the code I'm using in a tarball, in case people have any > suggestions. tar's don't attach to the list, use a JIRA. Carl. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org