Edge runtime slower than Node runtime?
Unanswered
Allegheny mound ant posted this in #help-forum
Allegheny mound antOP
I wanted to test out Edge functions, to see how efficient they are.
Git repo: https://github.com/amirakbulut/next-auth-credentials
Live: https://next-auth-credentials-topaz.vercel.app/dashboard
(you can login without credentials)
You'll see buttons in the dashboard, that call the same function but on different runtimes (edge vs node)
Inspector's network tab shows that the Edge functions are slower than the Node functions, isn't this weird?
Based on all the hype around Edge functions, I understood that it's faster because of no cold starts.
Am I doing something wrong?
Git repo: https://github.com/amirakbulut/next-auth-credentials
Live: https://next-auth-credentials-topaz.vercel.app/dashboard
(you can login without credentials)
You'll see buttons in the dashboard, that call the same function but on different runtimes (edge vs node)
Inspector's network tab shows that the Edge functions are slower than the Node functions, isn't this weird?
Based on all the hype around Edge functions, I understood that it's faster because of no cold starts.
Am I doing something wrong?
7 Replies
if it consumes cpu cycle, for instance, it receives big size of json response, it consumes cpu to deserialize it into JS object, which Edge Runtime is not good at compared to AWS Lambda.
other thing is, if the upsteam api sits closely together with AWS Lamda(Node.js) like in the same region, it could be blazing fast compared to Edge Runtime, say AWS Lambada is in US east, hitting from Edge server in Tokyo, it takes 300ms one way.
other thing is, if the upsteam api sits closely together with AWS Lamda(Node.js) like in the same region, it could be blazing fast compared to Edge Runtime, say AWS Lambada is in US east, hitting from Edge server in Tokyo, it takes 300ms one way.
@tafutada777 if it consumes cpu cycle, for instance, it receives big size of json response, it consumes cpu to deserialize it into JS object, which Edge Runtime is not good at compared to AWS Lambda.
other thing is, if the upsteam api sits closely together with AWS Lamda(Node.js) like in the same region, it could be blazing fast compared to Edge Runtime, say AWS Lambada is in US east, hitting from Edge server in Tokyo, it takes 300ms one way.
Tomistoma
Do you mean "if it receives a big JSON request"?
in general, to pass data via network, language variables need to be converted into byte streams. all of languages such as JavaScript, Java, Go, Rust whatever, this convention processes consume CPU cycles a lot. so if payload, JSON response from upstream api is so large, it consumes CPU.
on top of that, Edge Runtime, which is Cloudflare Worker, is designed for I/O bound tasks, so it is not good.
but streaming services like Vercel AI SDK, which just pass through response without parsing payload won’t consume cpu cycles.
@tafutada777 if it consumes cpu cycle, for instance, it receives big size of json response, it consumes cpu to deserialize it into JS object, which Edge Runtime is not good at compared to AWS Lambda.
other thing is, if the upsteam api sits closely together with AWS Lamda(Node.js) like in the same region, it could be blazing fast compared to Edge Runtime, say AWS Lambada is in US east, hitting from Edge server in Tokyo, it takes 300ms one way.
Allegheny mound antOP
Fetching/returning JSON seems like a very basic thing to me?
Giant panda
Haven’t read the messages so far but if your edge function is close to users and no longer close to DBs and other services it becomes naturally slower. Locality in terms of reducing the distance between services and functions is more important than the distance to users