<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
> On Jan 15, 2015, at 1:30 PM, Denis Makogon <<a href="mailto:dmakogon@mirantis.com">dmakogon@mirantis.com</a>> wrote:<br>
><br>
> Good day to All,<br>
><br>
> The question that i’d like to raise here is not simple one, so i’d like to involve as much readers as i can. I’d like to speak about oslo.messaging performance testing. As community we’ve put lots of efforts in making oslo.messaging widely used drivers stable as much as possible. Stability is a good thing, but is it enough for saying “works well”? I’d say that it’s not.<br>
> Since oslo.messaging uses driver-based messaging workflow, it makes sense to dig into each driver and collect all required/possible performance metrics.<br>
> First of all, it does make sense to figure out how to perform performance testing, first that came into my mind is to simulate high load on one of corresponding drivers. Here comes the question of how it can be accomplished withing available oslo.messaging tools - high load on any driver can perform an application that:<br>
>       • can populate multiple emitters(rpc clients) and consumers (rpc servers).<br>
>       • can force clients to send messages of pre-defined number of messages of any length.<br>
<br>
</span>That makes sense.<br>
<span class=""><br>
> Another thing is why do we need such thing. Profiling, performance testing can improve the way in which our drivers were implemented. It can show us actual “bottlenecks” in messaging process, in general. In some cases it does make sense to figure out where problem takes its place - whether AMQP causes messaging problems or certain driver that speaks to AMQP fails.<br>
> Next thing that i want to discuss the architecture of profiling/performance testing. As i can see it seemed to be a “good” way to add profiling code to each driver. If there’s any objection or better solution, please bring them to the light.<br>
<br>
</span>What sort of extra profiling code do you anticipate needing?<br>
<span class=""><br></span></blockquote><div><br></div><div>As i can foresee (taking into account [1]) couple decorators, possibly one that handles metering process. The biggest part of code will take highload tool that'll be a part of messaging. But another question adding certain dependecies to the project.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> Once we’d have final design for profiling we would need to figure out tools for profiling. After searching over the web, i found pretty interesting topic related to python profiling [1]. After certain investigations it does makes sense discuss next profiling options(apply one or both):<br>
>       • Line-by-line timing and execution frequency with a profiler (there are possible Pros and Cons, but i would say the per-line statistics is more than appreciable at initial performance testing steps)<br>
>       • Memory/CPU consumption<br>
> Metrics. The most useful metric for us is time, any time-based metric, since it is very useful to know at which step or/and by whom delay/timeout caused, for example, so as it said, we would be able to figure out whether AMQP or driver fails to do what it was designed for.<br>
> Before proposing spec i’d like to figure out any other requirements, use cases and restrictions for messaging performance testing. Also, if there any stories of success in boosting python performance - feel free to share it.<br>
<br>
</span>The metrics to measure depend on the goal. Do we think the messaging code is using too much memory? Is it too slow? Or is there something else causing concern?<br>
<span class=""><br></span></blockquote><div><p>It does make sense to have profiling for cases when trying to upscale cluster and it'll be a good thing to have an ability to figure out if scaled AMQP service has it's best configuration (i guess here would come the question about doing performance testing using well-known tools), and the most interesting question is about how messaging driver decreases (or leaves untouched) throughput between RPC client and server. This metering results can be compared to those tools that were designed for performance testing. And that's why it'll be good step forward having profiling/performance testing using high load technic.<br></p></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
><br>
><br>
><br>
> [1] <a href="http://www.huyng.com/posts/python-performance-analysis/" target="_blank">http://www.huyng.com/posts/python-performance-analysis/</a><br>
><br>
> Kind regards,<br>
> Denis Makogon<br>
> IRC: denis_makogon<br>
> <a href="mailto:dmakogon@mirantis.com">dmakogon@mirantis.com</a><br>
><br>
</span>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div><div class="gmail_extra">Kind regards,<br>Denis M.<br></div><div class="gmail_extra"><br></div></div>