feat(multi region setup): deploy lambda perf into multiple region

[sebnapo]

Deploy everything into 4 different regions (to start).

Everything seem's to work, at least on my computer setup.
I don't know how you create the underlying infrastructure (s3 buckets for example or ECR repositories) but you might need to deploy them in the new region (i've taken us-west-1, us-east-1, eu-west-1, eu-central-1).

Also, there is a breaking change in the github page, be carefull, you might want to run everything when you deploy it for the first time to production (I've updated the way you fetch data from the JS script). As I am not really great at web development, I think there is place for improvement on this side... Making 1 http call everytime you change a filter is not that optimized (we only need one call if the region changes, because file is different).

[maxday]

Hey! Thanks for your contribution!
Yeah, currently the load() is called once and filtering is done client side when you change filters. We might want to keep that.
Having more regions would also mean having more data -> bigger JSON -> bigger loading time.
I think having one single file for the UI would make sense but would require a change:

• keep all cold starts information (10 for now, but likely to be bumped to 100 very soon) in a file like 'data.complete.json'
• keep only front-end useful data in a other file like 'data.ui.json' (with only the average instead of having the full 10-data array)

This way we would still have the complete historical data on git + have a lightweight multi-region single file for the UI

WDYT?

[sebnapo]

Might be nice yes !

Actually, json data is structured this way :

{
"metadata": xxxxxx,
"runtimeData": [listOfRuntimes]
}

Do we add another dimension in the runtimeData like :

{
"metadata": xxxxxx,
"runtimeData": [{"eu-west-1": {allRuntimeForThisRegion}, "us-east-1": {sameForThisRegion}} ]
}

And for the ui-optimized one, the same but we remove the "i" field (the one with the init durations) ?

Would that work for you ?

[maxday]

I don't think there are region-specific runtimes so maybe :

{
  "memorySizes": [128, 256, 512, 1024],
  "regions":["us-east-1", "eu-west-1", xxx]
  "runtimes": [
    {

would make more sense?

[sebnapo]

Mmmh for the manifest yes that was my idea.

But i was talking about the results, the one that are actually commited to the github repo. We need to specify the region somewhere. And each region will have its own results, that why I proposed this json structure 📏

If we want to join everything in one single file, we will need to think about a way of retrieving all of the results from a single lambda (which will access every dynamodb table I guess ?). What is your opinion on that ?

[sebnapo]

What do you think about deploying the result builder into a single region ? Will need to have a proper role just for this one actually. My point is that I think that building the reports should work that way (for the multi region setup) :

• Having one function which iterate through the manifest to gather the different region name the stack is deployed into
• This function will basically do the same as the one you built, except that it will iterate other this list of regions
• Each iteration will produce a json which will be intricated to look like this :
  {"eu-west-1" : {"runtimeDate": xxxxx, "metadata": yyyyy}, "eu-central-1": {"runtimeDate": xxxxx, "metadata": yyyyy}}

This way we will have one central file which contains every data for one for multiple region.

Now, if we want to shorten the data that we have to ease the frontend when loading (more than true if you go 100 iterations a runtime), we will need to do the same thing, but shrink to the least amount of data needed. WDYT about :

runtimeData.push({
r: runtime,
p: packageType,
d: displayName,
i: initDurations, <= without this one line here ? which should be the big line because it containes all iteration
m: memorySize,
a: architecture,
mu: averageMemoryUsed,
ad: averageDuration,
acd: averageColdStartDuration,
});

Are there any other field that we dont need for filtering/display purpose ?

Another question that comes in mind, you wanna go with 100 iterations / runtime / memory ?
You might have trouble with lambda concurrency limits here (at least the soft limit imposed from AWS lol). How many are fired today ? I've seen more that 30 runtimes with 4 memory size so it is 1200 executions here but I guess you are comparing zip and image so x 2 on those ? 2400 for one trigger ?

If you bump it to 100, it's gonna go to 24.000, might need to increase this quotas (and hope you don't have other things using lambda in production at the same time lol)

What do you think about all that also ? (lots of question, reinvent flight back was productive :D)