Fork me on GitHub
#aws-lambda
<
2020-03-21
>
valtteri15:03:37

Cool! How is the cold startup time?

borkdude15:03:49

Don't know, ask Dainius I guess 🙂 @U0FT43GKV

borkdude15:03:13

normally bb starts within 13 ms on a laptop

valtteri16:03:16

I’ll give it a spin once I’m back on computer! Startup-time is usually not that critical to me but I’m just curious.

borkdude16:03:30

he did say to me that there was one issue in bb that prevented this from working, he's going to do a PR for that

valtteri16:03:00

Prevented what from working?

borkdude16:03:23

this is the lambda example

borkdude16:03:29

but he didn't tell me what, so I have no clue

borkdude16:03:37

we will know soon hopefully

valtteri17:03:08

I just tried and was able to deploy it to lambda. Had to make small modofikations to makefile on MacOS because it wasn’t happy with /tmp/....

valtteri17:03:38

the first call took 486.57 ms which is fast imo.

valtteri17:03:41

And second cold call was 484.16 ms. So we could say it’s < 500ms 🙂

Dainius Jocas17:03:29

Hi, yeah, the cold start is 400ms, subsequent calls are 30ms. Worth mentioning is that the cold start and the duration depends on how much RAM is dedicated to the lambda, the more the faster lambda is.

valtteri18:03:25

Yep I saw variance between 4ms and 120ms on hot calls with 128Mb RAM. Which I think is quite good.

Dainius Jocas18:03:22

Without the change Lambda fails in a very similar way as is described here https://github.com/oracle/graal/issues/841

Dainius Jocas18:03:57

Also, I've found very similar issue https://github.com/quarkusio/quarkus/issues/4262. Here it is said that

You can work around the problem by defining the environment variable DISABLE_SIGNAL_HANDLERS to any value. Obviously this means that you won't have OS signal handling though.
Maybe the environment variable for babashka should be the same?

Dainius Jocas18:03:01

It is. I'm just not sure on how to name the environment variable. But my overall solution is just a quick and dirty hack to make the thing work. Probably more sophisticated design is needed to support Lambda use case.

borkdude19:03:56

So far babashka specific env variables starts with BABASHKA_, like BABASHKA_CLASSPATH. What about BABASHKA_DISABLE_PIPE_HANDLER?

borkdude19:03:17

Pipe handling doesn't work on Windows either

Dainius Jocas19:03:58

ok, I'll rename the env variable in the PR

borkdude19:03:32

merged. I assume you don't need a new build? btw, @U6N4HSMFW - for you it did work right, without this patch?

Dainius Jocas19:03:19

A new build would be nice because in the lambda archive I'm packaging the bb binary. For the example lambda I've deployed a babashka docker to Docker Hub https://hub.docker.com/r/dainiusjocas/babashka and then used it to build lambda archive. So, if babashka would provide a build, I'd adjust the example. Propably, later I'd convert it into a template project.

borkdude19:03:22

There are pre-release builds in #babashka_circleci_builds - I'll hope to release a new one soon.

Dainius Jocas19:03:22

Perfect! No worries, I'm in no rush 🙂

valtteri19:03:34

@U04V15CAJ correct, it worked without the patch

borkdude19:03:52

@U6N4HSMFW Hmm, so maybe the patch isn't needed then - or is there something different in your env @U0FT43GKV

Dainius Jocas19:03:06

The patch is needed, I've packaged the patched version of bb to a docker, and then used the patched bb for building the lambda in the docker.

FROM dainiusjocas/babashka:latest as BABASHKA

FROM clojure:tools-deps-alpine as BUILDER
RUN apk add --no-cache zip
WORKDIR /var/task

COPY --from=BABASHKA /usr/local/bin/bb bb

ENV GITLIBS=".gitlibs/"
COPY lambda/bootstrap bootstrap

COPY deps.edn deps.edn

RUN clojure -Sdeps '{:mvn/local-repo "./.m2/repository"}' -Spath > cp
COPY src/ src/
COPY resources/ resources/

RUN zip -q -r function.zip bb cp bootstrap .gitlibs/ .m2/ src/ resources/ deps.edn
See the first line here.

borkdude19:03:20

ah, that is why your code worked for valtteri, this makes sense. thanks

👍 8
borkdude22:03:04

@U0FT43GKV I wonder if a simple try/catch would have also sufficed as a workaround to this

borkdude22:03:18

Or was it more like a hard unrecoverable crash?

borkdude22:03:16

if try/catch around handle-pipe! works, then that would be preferable I think

borkdude22:03:16

also, this commit ought to have fixed the problem: https://github.com/dmlloyd/graal/commit/dedcc86471b0209eeebf1df816b5f2590dc3361d which version of graalvm did you use to compile your docker image?

Dainius Jocas22:03:42

I haven't tried try/catch. Here is the error message from logs https://gist.github.com/dainiusjocas/feafeef5653ff2c6e8c7b2d9627a831d

Dainius Jocas22:03:00

I've used the same version as is specified in the Dockerfile

borkdude22:03:40

Looking at that log, I suspect try/catch won't do it, but you could give it a try if it's not too much to ask. I did release v0.0.78 now and renamed the variable to BABASHKA_DISABLE_PIPE_SIGNAL_HANDLER

Dainius Jocas23:03:10

Tomorrow I'll try the try/catch approach. I also suspect that it will not work because lambda runtime panics when lambda tries to do anything with signals. But I'll try

borkdude10:03:15

OK, thanks. I'll await your results.

borkdude10:03:37

I think it might also be good to post an issue about this to oracle/graal, since it seems they intended to fix the issue

borkdude10:03:04

instead of us working around it

Dainius Jocas18:03:03

I've tried with try/catch. The same failure.

borkdude18:03:01

ok, then our decision was good

Dainius Jocas21:03:58

It turns out that lambda runtime has curl. So no external dependencies needed. Then the issue is to parse curl response with headers. @U04V15CAJ do you plan to support parsing curl response into {:headers {} :body "" :ect :etc} in babashka.curl?

borkdude21:03:54

@U0FT43GKV Cool. I think it's good to have support for this, but it's not currently implemented.

Dainius Jocas21:03:24

Another issue with using curl is that it is much much slower, than clj-http-lite. The echo took 200ms consistently to execute while clj-http-lite take 15ms. Here is my naive implementation of curl response parsing https://gist.github.com/dainiusjocas/d2a5ca60ae25cd260f37b7c125a0b2e6

borkdude21:03:33

why would curl be slower you think?

borkdude21:03:12

I made an issue for parsing the headers here: https://github.com/borkdude/babashka.curl/issues/5 I think this should be optional, so maybe when passed an option like :response true will return the full response map and when it's not set, it will return only the body?

Dainius Jocas21:03:24

no idea why it could be that much slower.

Dainius Jocas21:03:43

IMO, the current functionality should not change, so this response parsing should under some new param like :response true. Note that response headers are retrieved with :raw-args ["-i"]

borkdude21:03:33

yeah, so when :response true, use the "-i" argument implicitly

borkdude22:03:21

FWIW I see similar times between babashka.curl and slurp

user=> (time (do (curl/get "") nil))
"Elapsed time: 75.406528 msecs"
nil
user=> (time (do (slurp "") nil))

borkdude08:03:00

@U0FT43GKV Could it be that the slowness with curl was with repeated execution of requests? Maybe clj-http-lite uses connection pooling?

Dainius Jocas09:03:05

I doubt that the slowness is because connection pooling. As it is written in the README No persistent connection support

Dainius Jocas09:03:40

I have a suspicion that it might be because doing shell out on a very constrained environment, just 128MB RAM and very little CPU. I would like to test with more RAM given to the lambda and some profiling.

Dainius Jocas09:03:37

I have an idea to package babashka as a Lambda layer, and make a proper template that uses handler option, that would be a script file. In this way one could write a lambda function right in the cloud IDE or the packaging script could produce --uberscript for compactness. @U04V15CAJ what do you think if I publish babashka as a public lambda layer?

borkdude09:03:10

:thumbsup:

👍 4
borkdude11:03:16

@U0FT43GKV Btw, if you want to develop babashka.curl you can load it with bb from the classpath with :reload, instead of the built-in one.