> Yep. At AT&T, we had to disable calls to GET /resources without any
> filters on it. The call would return hundreds of thousands of records,
> all being JSON-ified at the Ceilometer API endpoint, and the result
> would take minutes to return.
so the performance issue with resource-list is somewhat artificial... the
gathering of resources itself can return back in seconds with over a
million records... the real cost is that the api also returns a list of
all related meters for each resource. if i disable that, resource-list
performance is decent (debatable).
> the main problem with the get_resources() call is the
> underlying databases schema for the Sample model is wacky, and forces
> the use of a dependent subquery in the WHERE clause  which completely
> kills performance of the query to get resources.
Jay, i've begun the initial steps to improve sql model and would love to
get your opinion. i've created a bp here:
https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql (i use 'big
data' in quotes...)
Regarding the < 2 second requirement. i haven't seen the number of records
tempest generates but i would expect sub 2 seconds would be a good target.
that said, as Jay mentioned, as the load/test increases there's only so
much performance you can get with hundred thousand to millions of records
using an sql backend... at the very least it's going to flutuate (how much
is acceptable i have no clue currently).
openstack, ibm software standards
OpenStack-dev mailing list