No idea why e2e response time is too high than in my log
Hi
My request took too long and I want to debug, but I have no idea with this, I've calculated by my self it is only 100ms but in chrome devtool it shows 1.5s, any idea why? Tried > 3 times but the same result
Account id: 5c6fbc8f1990d244d873173b28cc8381
11 Replies
Hi anybody here can help 👋
Hi @Community Champion I'm not sure if tagging is appropriate in this situation. If you has every experienced this please help me in this case? Thanks!
?pings
Please do not ping community members for non-moderation reasons. Doing so will not solve your issue faster and will make people less likely to want to help you.
Sorry I don't know about this 🙏
Still debugging this, if anyone experienced this please help me 🙏 really appreciate it
Hi if anyone know this please help me, still struggling with this
you're logging just the time it took to get the response headers of your fetch request, not even the content, def not the full end to end time
could be other middleware in the way, could be your latency to the cf location (check https://beta.bannerify.co/cdn-cgi/trace, colo= for airport code of location you hit), etc. You've only got one piece of the puzzle
@Chaika sorry for my late I just giving up because no support
thanks for your support.
you're logging just the time it took to get the response headers of your fetch request, not even the content, def not the full end to end timeDid you mean it can be my response is quite large so the content transforming, reading, etc... can increase a bit? I don't think 200kb can make that difference... hmmm
could be other middleware in the way, could be your latency to the cf location (check https://beta.bannerify.co/cdn-cgi/trace, colo= for airport code of location you hit), etc. You've only got one piece of the puzzleYes I've think about this but I don't find out any reasonable root cause, latency from my country to cf location is fine (VN(Ha Noi) -> HKG), and I've tested a fresh script respond within 30ms. Even when I make the route (in that screenshot) return immediately a response it's still 100ms, so I wonder is there anything after my worker handle the content. After spend a week on this, I just figured out if I removed the resvg transformer code (so my route return svg instead of png) it reduced from 1.5s to 300ms (end to end), which is a lot, from here I've more question: - Why resvg takes that much response time, in Vercel and my local I've tested the same code it's only 200-300ms, not 1.2s. But the weird thing is in another worker on cloudflare (run by the others, open source), the speed is fine, fast x2 or x3 than me but same svg file, same resvg version, same wasm file. - If it's because resvg/wasm, why I couldn't measure the time correctly on cloudflare. My assumption is about sync and async since wasm usually return sync - It's because resvg or wasm, what should I do to speed up its work - If it's not because resvg or wasm, what else should I check, I don't know anything except my code I'm now very confused, not sure to debug this 🙏 If you can help I appreciate it a lot
Did you mean it can be my response is quite large so the content transforming, reading, etc... can increase a bit? I don't think 200kb can make that difference... hmmmThis is your request: You -> Network -> Cloudflare -> Worker/Pages -> Pages Middleware -> Pages OnRequest -> Pages onRequest Work (you are measuring this from the worker)-> Pages Middleware -> Workers/Pages -> Cloudflare -> Network -> You I'm not sure what app.fetch is doing, but if it's a simple fetch request, you're not measuring the time for content/body to be streamed through either. For the rest of your questions, would need more explanation what you're doing with resvg exactly/what is app.fetch doing. If it's wasm that was slowing it down, it'd make sense as timers only move when network, i/o. https://developers.cloudflare.com/workers/runtime-apis/performance/, so the time you'd see with your timing would be purely just the remote fetch time
Ah sorry I think you're misundestand of name app.fetch
app.fetch is point to to hono.fetch so basically it call to my route. The route is not just fetch request, it call to db, generate svg, convert svg to png, return image, that is. I don't think I have any hidden magic here. And the result is about 200kb, I don't think content/body would be a problem here
would need more explanation what you're doing with resvg exactly/what is app.fetch doing.resvg is a lib convert svg to png and I'm using for exactly that job. Let me explain again my route so you have clearly overview of what is it doing - call to db (use cache if possible) - transform rows from db to a svg - transform svg to png through resvg
If it's wasm that was slowing it down, it'd make sense as timers only move when network, i/o. https://developers.cloudflare.com/workers/runtime-apis/performance/, so the time you'd see with your timing would be purely just the remote fetch timeThis is new to me, does that mean wasm/resvg is not an I/O execution? As I checked via tracing, both resvg and satori(svg generate) always 0. If so, that's make sense, could be resvg's time can't measure through Date.now(). @Chaika forgot to mention
This is new to me, does that mean wasm/resvg is not an I/O execution? As I checked via tracing, both resvg and satori(svg generate) always 0. If so, that's make sense, could be resvg's time can't measure through Date.now().Right, wasm would all be cpu work, clock won't advance for that. It'd only advance for the db call if you were using local dev it would always advance though, could use that to try to see what exactly is so slow. How big is resvg?
But the weird thing is in another worker on cloudflare (run by the others, open source), the speed is fine, fast x2 or x3 than me but same svg file, same resvg version, same wasm file.Sounds like it may dependent on your input as well/other settings?
it's quite fast though, even other worker running resvg still fast
but I don't think it's from worker side, will check from my setting or something else, lib version, worker size etc
I think that's enough for my case, thanks for your support 🙇
yea I would just try to grab the most minimal repro. Pages Functions are just Workers under the hood