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