Clojurians Log v2

yeah, the warmup

Fargate maybe

I think it was (ab)using cloudwatch or some kind of health check

at the AWS day the amazon lot said to use cloudwatch to ping as a workaround which was a bit eek

Hey, I’ve got a stupid idea!

Pinging is vaguely efficient in keeping a small pool active, right?

but it fails at preventing cold starts when the pool is depleted, right too?

If in each lambda we probabilisticly determine to invoke the lambda again (just for warmup) then we dynamically warm up more instances.

@viesti @dominicm @alex.lynham am I nut?

nut, you, never!

so haven’t done investigation, but there were some posts that every 4hours the cluster reboots

so there is at least that kind of cold start

each deploy is cold start

yeah they randomly bring the lambda instances down every once in a while

so you have cold starts from not being used & cold starts from instances being cycled

the cold start cycle for cluster reboot starts at lambda creation, I think

but 👍 for probabilistic warmup

there’s two uses

production and repl

which have different strategies

if your lambda is active enough it’s deployed on several containers so on cycling you lose only some of your caapacity, not all

very true

I guess as long as there's at least a small pool at any given time you should be golden

when we used to shuffle around v large volumes in amazon we had to warm things as part of a deployment step so sometimes hacks are needed

¯\(ツ)/¯

I’m looking for a reference for this statement > The container is not used for a second invocation until the first one finishes.

I read that on hackernoon, they may have a reference.

https://github.com/kotarak/vimpire/compare/db0d3503137703acc7c30b29cc6b8e1ed358e953...0218d045b4f520474ffc6f2bc51dfbab66891e98

I have written a crude simulator: https://gist.github.com/cgrand/8a57d5761d2c5c5ab5dbec25d5d0c823

@cgrand shared a file: https://clojurians.slack.com/files/U3E46Q1DG/F9QFZEBEG/lambda-sim.clj

under constant load (which is the best case for Lambda), the number of perceived cold starts would be almost halved with probabilistic warmup

Something beyond the README?

hmm, at which point does it cost more to keep warm lambdas then to run an on-demand ec2 (cost dependa on instance type)

disclaimer: my sim worst sin may be temporal aliasing

Yeah. I think you're basically inventing ec2 when you do a warm lambda.

There’s a bit more work and integration to do with ec2.

When I suggested probabilistic warmup it was to ensure there was always a buffer of ready containers to diminish latency on activity bursts.

> work and integration There is? ASGs are fairly well explored. You set them to a minimum of X and you're good to go? Maybe I'm used to the convenience of terraforn/cloudformation managing that stuff

yes it’s not about autoscaling it’s about “packaging”

/github subscribe portkey-cloud/portkey

/github subscribe portkey-cloud/aws-clj-sdk

hmh, didn’t figure out how to put documentation key into shape: https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-models/src/main/resources/models/elasticfilesystem-2015-02-01-model.json#L28

haa, almost, there are more documentation keys in the maven packaged model

portkey.awsgen> (generate-files!)
generating “appsync” “2017-07-25"
generating “events” “2015-10-07"
skipping portkey.aws.events.-2015-10-07 protocol “json”
generating “elasticfilesystem” “2015-02-01”
generating “serverlessrepo” “2017-09-08”
ExceptionInfo In: [1 1 “SourceCodeUrl” 1 1 0] val: “locationName” fails at: [:members 1 1 :querystringmap :shape 0] predicate: #{“shape”}

nearly there

hum, serverlessrepo appeared quite recently