<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Hi stackers!</div><div class=""><br class=""></div><div class="">In Mitaka new oslo.messaging driver for RabbitMQ is released (pika driver).</div><div class="">I would like to share information about current state of pika driver and plans for improvements</div><div class="">during next release cycle</div><div class=""><br class=""></div><div class="">Now we have driver implementation which:</div><div class="">1) passes all tempest tests</div><div class="">2) implements heartbeat mechanism properly (uses pika implementation instead of implementing by own, like kombu driver does)</div><div class="">3) implements fast detection of connection problem (tcp_user_timeout usage for sending, heartbeats for listening)</div><div class=""> and reconnection to next available connection node (works better with RabbitMQ cluster then kombu)</div><div class="">4) implements pure at-most-once message processing for RPC if retry=0 is set for message sending </div><div class="">(kombu driver does not guarantee at-most-once processing even with retry=0 because uses acknowledges)</div><div class="">5) is about 50% faster then kombu (at least in my simple test with simulator.py - 1 rpc server process and 1 rpc client process, each client runs 5 threads):</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><i class="">results for rabbit: 330.2 msg/sec</i></div><div class=""><i class=""> <span class="Apple-tab-span" style="white-space:pre"> </span>results for pika: 497.6 msg/sec</i></div><div class="">6) eats RabbitMQ a bit more then kombu (especially mandatory flag for rpc to fail fast if nobody listen target).</div><div class=""> Therefore in performance testing (17 rpc server processes and 17 rpc client processes, each client runs 5 threads),</div><div class=""> when RabbitMQ cluster is overloaded, pika driver works about 10% slower in rpc call. My results:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><i class="">results for rabbit: 3097 msg/sec</i></div><div class=""><i class=""><span class="Apple-tab-span" style="white-space:pre"> </span>results for pika: 2825 msg/sec</i></div><div class=""> but casts work faster about 17% then kombu because it is more lightweight and RabbitMQ is not so heavy loaded in my tests:</div><div class=""> <i class=""> results for rabbit: 5687 msg/sec</i></div><div class=""><i class=""><span class="Apple-tab-span" style="white-space:pre"> </span>results for pika: 6697 msg/sec</i></div><div class="">7) implements separately notifications and rpc messaging (using different exchanges, etc) which allows to use different configuration</div><div class=""> for different use cases (for example durable notification messaging and not durable rpc messaging)</div><div class=""><br class=""></div><div class="">Plans for future development:</div><div class="">1) Implement configurable message serialisation (json - current implementation, msgpack)</div><div class="">2) Implement configurable connection factory (pool of connection - current implementation, single connection)</div><div class="">3) Now it is impossible to perform rolling update from kombu to pika, we need to implements some solution for cross driver rolling update</div><div class="">4) Polishing, bug fixing, profiling etc., as usual</div><div class=""><br class=""></div><div class="">P.S. Thank everyone who have been helping to develop pika driver!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>
</body></html>