For clarification, this is 3-4 PM (15:00 - 16:00) UTC, correct ?. -mark
----- Original Message ----- > From: "Dina Belova" <dbel...@mirantis.com> > To: "Matt Riedemann" <mrie...@linux.vnet.ibm.com> > Cc: "OpenStack Development Mailing List" <openstack-...@lists.openstack.org>, > openstack-operators@lists.openstack.org > Sent: Monday, November 9, 2015 4:30:55 AM > Subject: Re: [Openstack-operators] [openstack-dev] Performance Team summit > session results > > Folks, > > due to the doodle <http://doodle.com/poll/wv6qt8eqtc3mdkuz#table> 3:00 - > 4:00 UTC Tuesdays (starting from tomorrow) is ok for all voted people. > Although for the US folks with PST time zone it'll be very early due to the > time zone change happened for US on November, 1st. Still hope seeing you > there on *#openstack-performance* channel :) > > I've created primary wiki pages for the team > <https://wiki.openstack.org/wiki/Performance_Team> and its meetings > <https://wiki.openstack.org/wiki/Meetings/Performance> - please feel free > to add more items to the agenda. > > See you tomorrow :) > > Cheers, > Dina > > > On Mon, Nov 9, 2015 at 5:38 PM, Dina Belova <dbel...@mirantis.com> wrote: > > > Matt, > > > > thank you so much for covering [1], [2] and [3] points - I'll ping folks > > who've written these lines directly and will try to find out the answers. > > > > Cheers, > > Dina > > > > On Fri, Oct 30, 2015 at 1:42 AM, Matt Riedemann < > > mrie...@linux.vnet.ibm.com> wrote: > > > >> > >> > >> On 10/29/2015 10:55 AM, Matt Riedemann wrote: > >> > >>> > >>> > >>> On 10/29/2015 9:30 AM, Dina Belova wrote: > >>> > >>>> Hey folks! > >>>> > >>>> On Tuesday we had great summit session about performance team kick-off > >>>> and yesterday it was a great LDT session as well and I’m really glad to > >>>> see how much does the OpenStack performance topic is important for all > >>>> of us. 40 minutes session surely was not enough to analyse everyone’s > >>>> feedback and bottlenecks people usually see, so I’ll try to finalise > >>>> what have been discussed and the next steps in this email. > >>>> > >>>> Performance team kick-off session > >>>> ( > >>>> https://etherpad.openstack.org/p/mitaka-cross-project-performance-team-kick-off > >>>> ) > >>>> > >>>> can be shortly described with the following points: > >>>> > >>>> * IBM, Intel, HP, Mirantis, Rackspace, Red Hat, Yahoo! and others were > >>>> taking part in the session > >>>> * Various tools are used right now for OpenStack benchmarking and > >>>> profiling right now: > >>>> o Rally (IBM, HP, Mirantis, Yahoo!) > >>>> o Shaker (Mirantis, merging its functionality to Rally right now) > >>>> o Gatling (Rackspace) > >>>> o Zipkin (Yahoo!) > >>>> o JMeter (Yandex) > >>>> o and others… > >>>> * Various issues have been seen during the OpenStack cloud operating > >>>> (full list can be found here - > >>>> https://etherpad.openstack.org/p/openstack-performance-issues). > >>>> Most > >>>> mentioned issues were the following: > >>>> o performance of DB-related layers (DB itself and oslo.db) - it is > >>>> about 7 abstraction DB layers in Nova; performance of Nova > >>>> conductor was mentioned several times > >>>> o performance of MQ-related layers (MQ itself and oslo.messaging) > >>>> * Different companies are using different standards for performance > >>>> benchmarking (both control plane and data plane testing) > >>>> * The most wished output from the team due to the comments will be: > >>>> o agree on the “performance testing standard”, including answers > >>>> on the following questions: > >>>> + what tools need to be used for OpenStack performance > >>>> benchmarking? > >>>> + what benchmarking meters need to be covered? what we would > >>>> like to compare? > >>>> + what scenarios need to be covered? > >>>> + how can we compare performance of different cloud > >>>> deployments? > >>>> + what performance deployment patterns can be used for various > >>>> workloads? > >>>> o share test plans and perform benchmarking tests > >>>> o create methodologies and documentation about best OpenStack > >>>> deployment and performance testing practices > >>>> > >>>> > >>>> We’re going to cover all these topics further. First of all IRC channel > >>>> for the discussions was created: *#openstack-performance*. We’re going > >>>> to have weekly meeting related to current progress on that channel, > >>>> doodle with the voting can be found here: > >>>> http://doodle.com/poll/wv6qt8eqtc3mdkuz#table > >>>> (I was brave enough not to include timeslots that were overlapping > >>>> with some of mine really hard-to-move activities :)) > >>>> > >>>> Let’s have next week as a voting time, and have first IRC meeting in our > >>>> channel the week after next. We can start our further discussions with > >>>> “performance” and “performance testing” terms definition and > >>>> benchmarking tools analysis. > >>>> > >>>> Cheers, > >>>> Dina > >>>> > >>>> > >>>> > >>>> __________________________________________________________________________ > >>>> > >>>> OpenStack Development Mailing List (not for usage questions) > >>>> Unsubscribe: > >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>>> > >>> Thanks for writing this up, it's great to see people getting together > >>> and sharing info on performance issues and trying to pinpoint the big > >>> ones. > >>> > >>> I poked through the performance issues etherpad and was wondering how > >>> many people with DB issues, particularly for nova-conductor, are using a > >>> level of oslo.db that's new enough to be using pymysql rather than > >>> mysql-python because from what I remember there were eventlet issues > >>> without pymysql. That was added to oslo.db 1.12.0 [1]. > >>> > >>> The nova-conductor workers / CPU usage is also a known issue in the > >>> large ops gate job [2] but I'm not aware of anyone spending the time > >>> drilling into what exactly is causing a lot of that overhead and if any > >>> of it is abnormal. > >>> > >>> Finally, wrt DB, I'd also be interested to know if Rackspace, or anyone > >>> else, is still running with the direct-to-sql stuff that comstud wrote > >>> for nova [3] and if that still shows significant performance > >>> improvements over using sqlalchemy ORM. Not to open that can of worms in > >>> the -dev list here again, but it'd be an interesting data point. > >>> > >>> [1] https://review.openstack.org/#/c/184392/ > >>> [2] https://review.openstack.org/#/c/228636/ > >>> [3] https://blueprints.launchpad.net/nova/+spec/db-mysqldb-impl > >>> > >>> > >> Oops, forgot to copy the ops list on the last reply. > >> > >> -- > >> > >> Thanks, > >> > >> Matt Riedemann > >> > >> > >> _______________________________________________ > >> OpenStack-operators mailing list > >> OpenStack-operators@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >> > > > > > > > > -- > > > > Best regards, > > > > Dina Belova > > > > Software Engineer > > > > Mirantis Inc. > > > > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators