Scale up not working correctly about dynamodb-lambda-autoscale

[tmitchel2]

I thought this might be because I've not tested the write side as much as the read but i just did a local test again for myself and it seems to be scaling it fine for me.

Ensure you are running it every minute, it only looks a minute in the past to gather the statistics. Perhaps the statistics aren't available for some reason and its giving a false value. I might need to look something like 5 - 10 minutes in the past instead but that would slow down the provisioning correction unless i applied some smarter math to the statistic data points.

Also, maybe put the following debug logging into Config.js on line 110
log(JSON.stringify({data, isAboveThreshold, isBelowMin}, null, 2));
And update the import on line 4 to
import { log, invariant } from '../src/Global';

That should log the all data from cloudwatch which it uses to determine the write increment.

Please give it a go and let me know what the results are.

[mamoit]

I was running every minute (the logs said so), and even when I disabled the trigger and ran it locally it still didn't work.
I have the impression that it didn't get any datapoints from my hardcoded logs.
I'll try it again with your change asap.
Thanks 😄

[mamoit]

I can only try it in 12h or so.
May be related with the fact that I have multiple tables?

[mamoit]

Ok, got to do it earlier.
dynamic-dynamodb is working, and for eg reports right now 82.77% write usage, but dynamodb-lambda-autoscale reports:

    "ConsumedThroughput": {
      "ReadCapacityUnits": 0,
      "WriteCapacityUnits": 0
    }

[tmitchel2]

Definitely handles multiple tables but there's obviously something not right. Ill take another look in a few hours.

[tmitchel2]

Ok so I determined that taking an throughput average for the last minute in CloudWatch was a little too aggressive and would often give a 0 reading. I really want to maintain the incrementation agility as a feature so Ive altered the algorithm to take 5 one minute averages and pick the max value. Along with that change I've made various other changes including adding 100% flow coverage and some improved logging. I've done some quick minimal testing so please let me know if it doesn't work quite how you would expect.

[mamoit]

I can't currently test it for increases, but I can say that it is not decreasing as it should.
I've not had any read or write to any of the tables for quite some hours, maybe the lack of datapoints is a problem by itself?
The processing time also increased for the JS quite significantly (local test, didn't actually run on aws), maybe the extra computation for the averages is not such a good idea when the whole purpose of this may be to fit into the free tier of the lambda?

I'll test the increases Monday.
Thanks 👍

[tmitchel2]

The decreases have to work in a different way as you are only limited to 4 per calendar day so it may have been holding off on purpose. Ill put some specific logging in to make it easy to understand why it might not have decreased.

There shouldn't be any additional processing time at all, it's literally only doing the max of 5 numbers instead of taking 1. If you are running locally then a change in latency between calls might cause a slowdown. Ill take a look at it though.

[mamoit]

Yes, you must be right, the latency should have a great impact on the total processing time.
The duration must be because I was testing it on a different network than from where I normally test.

[tmitchel2]

Actually the stats logged out at the end should let you know where all the time is being spent. I've just made a checkin which improves the logging.

[gump59]

I was attempting to use the code before your latest updates and was having the same issue with it not scaling up. I updated to the latest and it is working now. BTW, I think your work on this is awesome, the coolest lambda for dynamo I have seen so far.

I added in a parameter to the config.env for filtering the table names based on a string such that a particular lambda will only operate on tables that match the string. It is pretty basic, and the first javascript I have written ever, but if is a feature you are interested in, I can put it into a public fork for you to see.

[tmitchel2]

As just mentioned in another ticket I'm refactoring the code to make these potential changes a little bit more obvious. I think commented out options is what ill go for. Please, hold on for my next commit and then lets see if your changes can fit in. Thanks...

[tmitchel2]

This should be resolved now, closing.