Something should probably change. The fundamental design issue is that we've got a 1:1 relationship between rule execution and database fetch. The rules may fire at several orders of magnitude different rates of speed from data refreshes in the database. So I'd think you would want to decouple the database fetch from the rule assertion.
# Shawn Hartsock ----- Original Message ----- > From: "Chris Friesen" <chris.frie...@windriver.com> > To: openstack-dev@lists.openstack.org > Sent: Friday, November 1, 2013 2:10:52 PM > Subject: Re: [openstack-dev] [nova][scheduler]The database access in the > scheduler filters > > On 11/01/2013 11:42 AM, Jiang, Yunhong wrote: > > Shawn, yes, there is 56 VM access every second, and for each VM > > access, the scheduler will invoke filter for each host, that means, > > for each VM access, the filter function will be invoked 10k times. So > > 56 * 10k = 560k, yes, half of 1M, but still big number. > > > I'm fairly new to openstack so I may have missed earlier discussions, > but has anyone looked at building a scheduler filter that would use > database queries over sets of hosts rather rather than looping over each > host and doing the logic in python? Seems like that would be a lot more > efficient... > > Chris > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
