
Fixes bug 1288372 Previously the performance of the /v2/resources API without constraints degraded sharply as the size of the meter collection grows, regardless of the number of known resources. We rationalize the underpinning storage driver method for mongo so as to rebase the query on the much smaller resource collection. This requires a subtle change in the semantic of the first and last sample timestamps which decorate the resource representation. These values are now defined respectively as being not later than youngest sample, and not earlier than the oldest timestamp, known for each resource. In order to maintain support for "tight" timestamp constraints on resource queries, we adopt a hybrid approach. For resource queries without timestamp constraints, we optimize with a simple query on the resource collection, but revert to a map-reduce on the meter collection for timestamp-constrained queries. The logic being that when one makes a resources query constrained by timestamp, one is essentially asking a question about samples, hence prepared to incur the cost of a query on the meter collection. Whereas for other constraints (user_id, project_id, source etc.) on the resources queries, one is more asking a question purely related to the resources themselves. Change-Id: Ifbf8932b4164f62bfda1cb3b8b9afe181051bc52
ceilometer
See the ReleaseNotes document and the project home for more info.
Description
Languages
Python
98.5%
Shell
1.3%
Mako
0.2%