Open Stack

> 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 [2] 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).

cheers,
gordon chung
openstack, ibm software standards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/4da9f186/attachment.html>