Open Stack

As Shawn Hartsock pointed out in the reply, I made a stupid error in the calculation. It's in fact 55 access per second, not that big number I calculated. 
I thought I graduated from elementary school but seems I'm wrong. Really sorry for the stupid error.

--jyh

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: Friday, November 01, 2013 9:18 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][scheduler]The database access in the
> scheduler filters
> 
> On 11/01/2013 09:09 AM, Andrew Laski wrote:
> > On 11/01/13 at 10:16am, John Garbutt wrote:
> >> Its intentional. Cells is there to split up your nodes into more
> >> manageable chunks.
> >
> > I don't think you mean to say that there's intentionally a performance
> > issue.  But yes there are performance issues with the filter scheduler.
> > Because I work on a deployment that uses cells to partition the workload
> > I haven't seen them myself, but there are plenty of reports from others
> > who have encountered them.  And it's easy to run some back of the
> napkin
> > calculations like was done below and see that scheduling will require a
> > lot of resources if there's no partitioning.
> >
> >>
> >> There are quite a few design summit sessions on looking into
> >> alternative approaches to our current scheduler.
> >>
> >> While I would love a single scheduler to make everyone happy, I am
> >> thinking we might end up with several scheduler, each with slightly
> >> different properties, and you pick one depending on what you want to
> >> do with your cloud.
> >
> > +1.  We have the ability to drop in different schedulers right now, but
> > there's only one really useful scheduler in the tree.  There has been
> > talk of making a more performant scheduler which schedules in a 'good
> > enough' fashion through some approximation algorithm.  I would love
> to
> > see that get introduced as another scheduler and not as a rework of the
> > filter scheduler.  I suppose the chance scheduler could technically
> > count for that, but I'm under the impression that it isn't used beyond
> > testing.
> 
> Agreed.
> 
> There's a lot of discussion happening in two different directions, it
> seems.  One group is very interested in improving the scheduler's
> ability to make the best decision possible using various policies.
> Another group is concerned with massive scale and is willing to accept
> "good enough" scheduling to get there.
> 
> I think the filter scheduler is pretty reasonable for the best possible
> decision approach today.  There's some stuff that could perform better.
>  There's more policy knobs that could be added.  There's the cross
> service issue to figure out ... but it's not bad.
> 
> I'm very interested in a new "good enough" scheduler.  I liked the idea
> of running a bunch of schedulers that each only look at a subset of your
> infrastructure and pick something that's good enough.  I'm interested to
> hear other ideas in the session we have on this topic (rethinking
> scheduler design).
> 
> Of course, you get a lot of the massive scale benefits by going to
> cells, too.  If cells is our answer here, I really want to see more
> people stepping up to help with the cells code.  There are still some
> feature gaps to fill.  We should also be looking at the road to getting
> back to only having one way to deploy nova (cells).  Having both cells
> vs non-cells options really isn't ideal long term.
> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev