[openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Yuriy Taraday yorik.sar at gmail.com
Fri Mar 21 16:32:45 UTC 2014


On Fri, Mar 21, 2014 at 2:01 PM, Thierry Carrez <thierry at openstack.org>wrote:

> Yuriy Taraday wrote:
> > Benchmark included showed on my machine these numbers (average over 100
> > iterations):
> >
> > Running 'ip a':
> >                                               ip a :   4.565ms
> >                                          sudo ip a :  13.744ms
> >                            sudo rootwrap conf ip a : 102.571ms
> >                                 daemon.run('ip a') :   8.973ms
> > Running 'ip netns exec bench_ns ip a':
> >                   sudo ip netns exec bench_ns ip a : 162.098ms
> >     sudo rootwrap conf ip netns exec bench_ns ip a : 268.115ms
> >          daemon.run('ip netns exec bench_ns ip a') : 129.876ms
> >
> > So it looks like running daemon is actually faster than running "sudo".
>
> That's pretty good! However I fear that the extremely simplistic filter
> rule file you fed on the benchmark is affecting numbers. Could you post
> results from a realistic setup (like same command, but with all the
> filter files normally found on a devstack host ?)
>

I don't have a devstack host at hands but I gathered all filters from Nova,
Cinder and Neutron and got this:
        method          :    min       avg       max       dev
                   ip a :   3.741ms   4.443ms   7.356ms 500.660us
              sudo ip a :  11.165ms  13.739ms  32.326ms   2.643ms
sudo rootwrap conf ip a : 100.814ms 125.701ms 169.048ms  16.265ms
     daemon.run('ip a') :   6.032ms   8.895ms 172.287ms  16.521ms

Then I switched back to one file and got:
        method          :    min       avg       max       dev
                   ip a :   4.176ms   4.976ms  22.910ms   1.821ms
              sudo ip a :  13.240ms  14.730ms  21.793ms   1.382ms
sudo rootwrap conf ip a :  79.834ms 104.586ms 145.070ms  15.063ms
     daemon.run('ip a') :   5.062ms   8.427ms 160.799ms  15.493ms

There is a difference but it looks like it's because of config files
parsing, not applying filters themselves.

-- 

Kind regards, Yuriy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140321/bd66f56c/attachment.html>


More information about the OpenStack-dev mailing list