One of the needs we've discussed for perfload is making sure
it is measuring when some inventory has been used.
Here, we change the perload job so that it creates the 1000 providers,
measures getting allocation_candidates and then, in a loop of 99, gets
a limited set of candidates, writes the first one back as an allocation
for a random consumer, project and user. At each iteration it measures
again.
This will make the log file a lot longer, but that's not a significant
issue: the numbers that matter will either be near the top or near the
end. If they are weird, looking in the middle will be informative. We
can tweak it.
This, as usual, is one of many ways to accomplish gathering some data.
Other options might include parallelizing the writes, but in this case
we are trying to see the impact of code on a single request, not on
concurrency.
At some point we will want to add nested and sharing into this mix.
Change-Id: I74b64a25f2be8fbbd01b3a3b438bba68de04b269
910b466c50