Anyone else experience 1.5-2s server response tim...
# help
d
Anyone else experience 1.5-2s server response times with simply the default example code for
sst.ApolloApi
? @Frank @thdxr Is this normal? I up’d the memory to 4096 and still averaging 1.5-2s This is just for a hello world reply. in comparison an actual Contentful api call takes avg 10ms
n
Have you tried deploying your app rather than running it locally to see if you have the same response times? Running locally is quite a bit slower but I believe they recently did an update that should help with it.
d
how do you mean running locally?
n
sst start
(points at your local code) vs
sst deploy
(builds and deploys your code)
d
I think you just blew my mind. I didn’t realize anything was running locally with sst start
I knew debug… but I thought that was in the cloud
n
Yeah I can’t explain exactly what’s happening but its doing some kind of proxy work to forward requests to your local machine, so I believe there’s an extra hop in there.
d
hmmm… THANKS! hope that was it… trying now
n
Again I’m pretty sure @thdxr was working on improving the local performance in one of the recent updates. I haven’t taken the time to upgrade yet to see if it’s improved my environment though.
d
oh I’m perfectly happy with those response times for DEV
but I thought that was prod
oh ya… that was it @Nick Laffey! down to 60-70ms now!
n
Nice!
d
wayyy better but still not 20-30ms
n
But at least its not 5 seconds 🙂
d
thanks again
n
Also I could be way off about things running “locally” it’s all magic to me right now.
Ah here’s where they explain how it’s working: https://docs.serverless-stack.com/live-lambda-development#sst-start
f
@Nick Laffey thanks for the clarification!
@Dan Van Brunt with
sst start
deploys a stub version of each Lambda function, and when a function gets invoked, it sends a websocket event to ur local, runs ur local code, and sends the response back to Lambda.
The 1.5-2s you are experience might be the network latency for the websocket roundtrip + spawning a node process locally to run your code.
The latter is often the slower part, and @thdxr made a fairly major improvement in the recent v0.47.0 update.
d
@Frank indeed that is what it was! So pumped that it was just dev. I was thinking I was talking crazy pills.