<div dir="ltr"><div><div><div><div><div><div><div>Hello,<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">My understanding is that your analysis is mostly based on running a<br>

profiler against the code. Network operations can be bottlenecked in<br>
other places.<br>
<br>
You compare 'simple script using kombu' with 'script using<br>
oslo.messaging'. You don't compare script using oslo.messaging before<br>
refactoring and 'after that. The latter would show whether refactoring<br>
was worth the effort. Your test shows that oslo.messaging performance<br>
sucks, but it's not definite that hotspots you've revealed, once<br>
fixed, will show huge boost.<br>
<br>
My concern is that it may turn out that once all the effort to<br>
refactor the code is done, we won't see major difference. So we need<br>
base numbers, and performance tests would be a great helper here.<br></blockquote><br>It's really sad for me to see so little faith in what I'm saying. <br>The test I've done using plain kombu driver was needed exactly to check that network is not the bottleneck for messaging performance.<br>
If you don't believe in my performance analysis we could ask someone else to do their own research and provide results.<br><br></div>Problem with refactoring that I'm planning is that it's not a minor refactoring that can be applied in one patch but it's the whole library rewritten from scratch.<br>
</div><div>Existing messaging code was written long long time ago (in a galaxy far far away maybe?) and it was copy-pasted directly from nova. <br>It was not built as a library and it was never intended to be used outside of nova.<br>
</div><div>Some parts of it cannot even work normally cause it was not designed to work with drivers like zeromq (matchmaker stuff).<br><br></div>The reason I've raised this question on the mailing list was to get some agreement about future plans of oslo.messaging development and start working on it in coordination with community.<br>
</div><div>For now I don't see any actions plan emerging from it. I would like to see us bringing more constructive ideas about what should be done.<br></div><div><br>If you think that first action should be profiling lets discuss how it should be implemented (cause it works for me just fine on my local PC). <br>
I guess we'll need to define some basic scenarios that would show us overall performance of the library. <br>There are a lot of questions that should be answered to implement this:<br>Where such tests would run (jenking, local PC, devstack VM)?<br>
How such scenarios should look like?<br></div><div>How do we measure performance (cProfile, etc.)?<br></div><div>How do we collect results?<br></div><div>How do we analyze results to find bottlenecks?<br></div><div>etc.<br>
</div></div><br></div>Another option would be to spend some of my free time implementing mentioned refactoring (as I see it) and show you the results of performance testing compared with existing code. <br>The only problem with such approach is that my code won't be oslo.messaging and it won't be accepted by community. It may be drop in base for v2.0 but I'm afraid this won't be acceptable either.<br>
<br></div>Regards,<br>Alexei Kornienko<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-30 17:51 GMT+03:00 Gordon Sim <span dir="ltr"><<a href="mailto:gsim@redhat.com" target="_blank">gsim@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/30/2014 12:22 PM, Ihar Hrachyshka wrote:<div class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alexei Kornienko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some performance tests may be introduced but they would be more<br>
like functional tests since they require setup of actual<br>
messaging server (rabbit, etc.).<br>
</blockquote></blockquote>
<br>
Yes. I think we already have some. F.e.<br>
tests/drivers/test_impl_qpid.<u></u>py attempts to use local Qpid server<br>
(backing up to fake server if it's not available).<br>
</blockquote>
<br></div>
I always get failures when there is a real qpidd service listening on the expected port. Does anyone else see this?<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>