Closed socketpair closed 9 years ago
Will profile why only ~200 ops per second. this is too small, even for so-slow-python.
investigation show that at least OrderedDict is slow. why it ever used? can it be eliminated?
Python in general should give about 3K/sec.... rabbitmq give nearly 50K/sec https://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/ http://jessearmand.com/blog/2013/06/11/im-sold-with-golang/ (I have re-checked these tests on my PC)
I can attach my RPC server and client sources written using your library. Can you help me to profile ? don't know who is slowing down. library or my code. or even broker....
So your proposal is to modify connect
so it sets TCP_NODELAY
by default, and allow clients to override it? That's fine by me, I'll accept a pull request
No, option is not needed. Since you never send big chunk of data with multiple send
syscalls, TCP_NODELAY will not hurt any way. So I consider you should always set this flag. This flag really is really hurt in modern applications since these app use internal buffering before sending and never repeatedly call send
syscall with small portions of data.
I'm happy to set the flag by default, but we really should provide a means by which to override it. It doesn't do any harm to make it overridable, and in my experience people will always want to reconfigure this sort of thing. No one likes working with overly-opinionated software.
connection = yield from asynqp.connect()
give RTT 0.04 sec (!) (i.e. 22 msg send/recv ops/sec)
give RTT 0.004 (i.e. 234 msg send/recv ops/sec)
RPC libraries should DIFINITELY set TCP_NODELAY on sockets.