In case of low desired RPM, number of subscriber instances going to negative

[RiflerRick]

the config environment variables that were used are:

      - TIME_SERIES_TICK_MS=1000
      - METRIC_POLL_TICK_MS=1000
      - TEMP_TABLE_PREP_SIZE_RATIO=0.10
      - PREP_PHASE_CHUNK_SIZE=1000000
      - TEMP_TABLE_RUN_SIZE_RATIO=0.10
      - RUN_PHASE_PUBLISH_CHUNK_SIZE=10000
      - RUN_PHASE_PUBLISH_SLEEP_TIME=200
      - APPROX_TABLE_SIZE=102157035

In case the RPM is given a low value, the number of instances going to a negative value. The most probable cause of this would be that the rate at which new instances are created because of the number of instances going zero is actually less than the rate at which instances are getting downscaled due to RPM

[RiflerRick]

This is actually a feature, not a bug.
From the picture the desired RPM given is 60 for create and the min and max subscribe sleep times are 10 and 500

b2/src/bombard.go

Line 671 in 8908cfa

c.minSubscribeSleepTime = 10

the sleep time it starts with is (10+500)/2.

b2/src/bombard.go

Line 307 in 8908cfa

msc.cM.sleepTime = map[string]interface{}{

The most probable scenario here is that the sleep time throughout is remaining low enough for the RPM to be higher than 60(which is a pretty low RPM).

[RiflerRick]

As a fix for this we can simply go ahead and change the values of the min and max subscribe sleep time to be 500ms and 5000ms in the very same places

b2/src/bombard.go

Line 671 in 8908cfa

c.minSubscribeSleepTime = 10

[RiflerRick]

https://github.com/RiflerRick/b2/pull/7/files#diff-d12a83a064d0575f7b203852c581f88dL671
This PR fixes the issue!

[RiflerRick]

Based on the value of the maxSubscriberSleepTime, it is possible to note, what would be the min RPM of the subscriber we are expecting for any queryType, if the desired RPM given is less than that min RPM, an error should be raised at the beginning aborting the script