<tt><font size=2>> Yep. At AT&T, we had to disable calls to GET
/resources without any<br>
> filters on it. The call would return hundreds of thousands of records,<br>
> all being JSON-ified at the Ceilometer API endpoint, and the result<br>
> would take minutes to return.</font></tt>
<br>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">> </font><tt><font size=2> the
main problem with the get_resources() call is the<br>
> underlying databases schema for the Sample model is wacky, and forces<br>
> the use of a dependent subquery in the WHERE clause [2] which completely<br>
> kills performance of the query to get resources.</font></tt>
<br>
<br><font size=2 face="sans-serif">Jay, i've begun the initial steps to
improve sql model and would love to get your opinion. i've created a bp
here: </font><a href="https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql"><font size=2 color=blue face="sans-serif">https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql</font></a><font size=2 face="sans-serif">
(i use 'big data' in quotes...)</font>
<br>
<br><font size=2 face="sans-serif">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).<br>
</font>
<br><font size=2 face="sans-serif">cheers,<br>
gordon chung<br>
openstack, ibm software standards</font>