Optimize reverse proxy about up HOT 9 OPEN

need to do some better measuring but it looks liek latency is already < 1ms so it might not be a big deal, especially with each Lambda container having a concurrency of 1 haha. Might as well check for some quick wins though :D

from up.

FWIW The product I'm launching on up will be running fasthttp at its core 🎉

from up.

@StoneCypher It's mandatory for now, since it relays events to the app you deploy. Honestly though it only introduces ~500μ, so it's nothing to worry about

from up.

I've been using fasthttp as I make my way thru learning Go. It's been treating me really well so far & I think it'd be a good fit here!

from up.

would it be reasonable to add opting out of the reverse proxy as an option?

from up.

Looks like this has been deprioritized, but wanted to add some thoughts in case anyone revisits.

Careful with unix domain sockets, you need to always spawn a random one to use - since containers are reused (and frozen), you have to always choose a different unix domain socket to prevent reuse errors.

I think switching to TCP / Unix domain sockets is a huge win over stdin / stdout simply because it eliminates oddness with accidentally logging to stdout. Eliminating that gotcha is worth way more valuable than speed IMO - plus TCP stacks are pretty dang fast these days.

Last point - if you're looking to tighten up speed, my spidey-sense tells me that the big win will be in eliminating the extra marshal / unmarshal pass that happens in the node.js shim (over stdout). Writing the reverse proxy in a language that is natively supported by lambda is going to have the biggest win is my intuition. (unless of course you're just banking on official go support).

And this might be sad, but I believe aws-lambda-go-shim uses a shared memory technique which is going to blow all of them out of the water.

from up.

@skabbes FWIW that stdout weirdness only really applies to the up proxy, at least no one else has to be aware of it (thank god haha).

Latency seems fine as-is but I wouldn't be too surprised if the serialization for big requests would be worth getting rid of, seems negligible for average stuff. Cold start is probably another story, it's ok but nothing fantastic, I read the post with their Python bindings and it seems cool but definitely more involved than the simple shim.

Reinvent is soon too, I'm banking on a whole bunch of new features. Curious to see what Go support would look like, installing pkgs takes longer than uploading a binary, so official support mightttt not help much.

from up.

@tj Ahh, ya I was confusing with go-apex, since I think you do have to be aware of stdout there.

FWIW, as a user of up in production, I love that I have the ability to read all the code and understand exactly what is going on. External reverse proxies, or things getting too magic would turn me off a bit.

installing pkgs takes longer than uploading a binary

I'd imagine that they'll just load your compiled code as a plugin, and put the compile requirements on you, so you get the same kind of speed. Pretty much, I think they'd just eliminate the need for the shim entirely. I'd even more love for them to add streaming upload and download support to APIGateway.

from up.

Oh man yeah, I'm sure that'll be comforting for a lot of people, and not relying on some little PaaS startup is a nice benefit too.

Trueee good point I forgot about plugins, that's a great use-case for it, seems like it'd slim down quite a bit:

   λ up (master): make size
2.2M	net/http.a
1.7M	runtime.a
1.1M	net.a
972K	reflect.a
860K	github.com/apex/up/vendor/github.com/aws/aws-sdk-go/aws/endpoints.a
648K	crypto/tls.a
496K	math/big.a
476K	text/template.a
404K	encoding/xml.a
388K	html/template.a
380K	text/template/parse.a
380K	syscall.a
380K	crypto/x509.a
376K	encoding/json.a
...

from up.