Fork me on GitHub
#portkey
<
2018-03-15
>
viesti07:03:47

yeah, the warmup

viesti07:03:52

Fargate maybe

dominicm10:03:22

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

alexlynham11:03:20

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

cgrand11:03:03

Hey, I’ve got a stupid idea!

cgrand11:03:13

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

cgrand11:03:14

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

cgrand11:03:43

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

viesti11:03:17

nut, you, never!

viesti11:03:27

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

viesti11:03:36

so there is at least that kind of cold start

viesti11:03:44

each deploy is cold start

alexlynham11:03:44

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

alexlynham11:03:05

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

viesti11:03:10

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

viesti11:03:44

but 👍 for probabilistic warmup

viesti11:03:48

there’s two uses

viesti11:03:50

production and repl

viesti11:03:00

which have different strategies

cgrand11:03:03

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

alexlynham11:03:40

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

alexlynham11:03:59

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

cgrand12:03:13

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

dominicm14:03:53

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

cgrand15:03:47

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

viesti15:03:14

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

cgrand16:03:25

disclaimer: my sim worst sin may be temporal aliasing

dominicm17:03:37

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

cgrand17:03:50

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

cgrand17:03:47

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

dominicm17:03:31

> 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

cgrand17:03:27

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

cgrand17:03:17

/github subscribe portkey-cloud/portkey

cgrand17:03:33

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

viesti19:03:11

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

viesti19:03:28

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”}

viesti19:03:31

nearly there

viesti19:03:05

hum, serverlessrepo appeared quite recently