Consumption Plan Scale with Blob Triggers

I wrote a .NET v1 app that is triggered off of blobs, with over 15,000 blobs to process. Each function run causes some data to get inserted into a DB as well as a `WAITFOR DELAY '00:00:25'` on the SQL Server. From what I read, I expected Azure Functions to just keep adding instances until it overloaded the DB, but that never happened. Instead, I seem to be stuck with 16 concurrent threads at any given time, resulting in 16-32 executions per minute. The app has been running for a half hour already, since about 3:30pm.


#### Investigative information

Please provide the following:

- Timestamp: 6/13/18 4:00 PM CT
- Function App version (1.0 or 2.0-beta): 1.0
- Function App name: throttledlf2
- Function name(s) (as appropriate): Function1
- Invocation ID:
- Region: North Central US

Here is the app I was using to create this scenario:
[FunctionThrottling.zip](https://github.com/Azure/azure-functions-host/files/2099901/FunctionThrottling.zip)

Should I be expecting this to scale more? When I didn't have the `WAITFOR` it scaled much quicker. Is it using execution time to determine how many instances to create?

NOTE: The whole purpose of this exercise is simply to make sure that Functions will not completely overload the DB. I had expected that it would and we would end up with Sql/Timeout Exceptions.

Start with the attached FunctionThrottling.zip and the Function1 blob-trigger entry point, then compare consumption-plan behavior with and without the 25-second SQL Server WAITFOR DELAY. Confirm whether the observed 16-thread limit is expected and document or correct the scaling behavior so the app's concurrency and database-load outcome are clear.

Written by the indexing model from the issue text.