No subject

Tue Apr 12 10:32:41 BST 2011

the same degrading performance that I did in a multi-host test. I also
observe the same thing on my workstation. I cut my testing short
before finding out where specifically the client and rabbit were
contributing to produce that curve.

If you do investigate libevent, you may find like I did that the
pyevent project suffers from poor releases. After years of fighting
with it we forked and created a separate pypi package with the latest
pyevent changes. Solving this problem with a ctypes library, and
possibly switching over to libev, are on my list of future projects.

I can't recall if pika was around when we first forked pyamqplib; we
chose libevent because we have fast HTTP -> AMQP gateways and needed
it on both sides of that bridge. Once we had something working, it
seemed like a good idea to publish, but it needed the rewrite that is
haigha to make it worth the effort. I also have learned a lot about
the protocol and wanted to put into practice some ideas on how to
write a good client.

If you like what you see perhaps we can figure out how to merge or
otherwise mutually improve haigha and pika. We recently used eventlet
to great success, which gave me inspiration to think about haigha with
an abstract connection layer. I found that since we only rely on
libevent in the Connection class, we're not far away from that design,
which I gather is also what pika is going for.

cheers,
Aaron

On Mon, May 16, 2011 at 3:01 AM, Gavin M. Roy <gmr at myyearbook.com> wrote:
> Hey Aaron, cool work. =A0Using libevent is a nice approach. =A0Given Pika=
's
> modular approach, I'll have to see what that looks like as an option in P=
ika
> v2.
> Given Jason's questions, I decided to port your bench to Pika and threw i=
n
> py-amqplib (single channel only) to boot.
> As I had expected,=A0Haigha benched faster than Pika, but surprisingly on=
ly by
> 2.84% with 500 channels. =A0I does, however, start to show its performanc=
e
> benefits on a single connection with multiple channels when the single
> socket is not over-saturated. =A0It was 13.29% faster than Pika with 50
> channels and 21.57% faster with 10 channels.
> I was somewhat surprised to find that Pika benched 13.08% faster with onl=
y 1
> channel. So surprised that I had to triple check the numbers ;-)
> I used the 500 number as the initial baseline because it the default valu=
e
> in your test app.=A0I am curious what the use case for so many channels i=
s in
> the test. =A0Is it to simulate concurrency in a client app?
> Anyway here is the info on my tests:
> Box:
>
> Dual quad core AMD 2.2Gz (Model 2356)
> 8GB Ram
> Max CPU utilization during all tests: 19%
> Max IOWait during all tests: 0.2%
> Gentoo Linux with a custom compiled 2.6.28 kernel
>
> RabbitMQ:
>
> 2.4.1
> Erlang R14B02
> Default settings
>
> Client libraries:
>
> Haigha 0.2.1
> Pika 0.9.6p0
> py-amqplib 0.6.1
>
> Test Parameters:
>
> Duration: 300 seconds
> Channel Count: 1, 10, 50, 500
> No-Ack: True
> Transactions: Off
> Single threaded
> Single Process
>
> The 1 channel option was to accommodate py-admqplib and BlockingConnectio=
n.
> =A0BlockingConnection can handle multiple channels but the overhead for
> setting up 500 connections on BlockingAdapter in Pika was prohibitive. =
=A0The
> test ended prior to all queues being bound and a single full setup is
> roughly 1.2 seconds in my environment. For the Pika/TornadoConnection tes=
t,
> I used Tornado 1.2.
> A few important things were uncovered in Pika with this test:
>
> There is an interesting recursion bug under heavy loads in all 0.9.x
> versions. This bug would only present itself if there was always a frame =
to
> read or frame to publish in the buffer. If the IOLoop ever had a cycle
> without inbound or outbound data, the bug will not present. =A0But if the=
re is
> always data to process, for up to 1,000 frames, there will be a
> RuntimeError. 1,000 is the default Python recursion limit. This bug has b=
een
> fixed.
> BlockingConnection is very slow! It is roughly 1/8th the speed of
> py-amqplib. While Asyncore can do roughly 1,800 messages a second on a
> single channel, Blocking can only do roughly 4!
>
> I didn't make much of an effort to clean up the code or remove the parts =
I
> don't use, but the stress_test app hack for pika is
> at=A0https://gist.github.com/974021
> Haigha looks nice. You're doing some of the things I have been thinking
> about with future versions of Pika such as in your haigha/classes modules
> (More natural AMQP mapping of classes for use in the client).=A0I look fo=
rward
> to seeing where you take it.
> Regards,
> Gavin
>
> On Saturday, May 14, 2011 at 9:40 PM, Jason J. W. Williams wrote:
>
> How does this differ from Pika's asyncore or Tornado bindings in terms of
> performance?
>

--=20
Aaron Westendorf
Senior Software Engineer
Agora Games
359 Broadway
Troy, NY 12180
Phone: 518.268.1000
aaron at agoragames.com
www.agoragames.com