another question:
another question:
we have a big monolitic worker that we deployed with d1 for each of our tenants and are currently converting to a microservice-esq architecture with many specialized workers and hyperdrive. it seems WAY faster than the monolitic api. we use the expressjs implementation that wasnt present when first deploying our monolith. we tried hyperdrive back then and it was solwer than now i swear :D do worker profit that much from beeing that much smaller and scoped?
26 Replies
Smaller workers require us to load less code from storage, so if you had a really big worker that does impact performance
Besides that, was your monolitic worker using dynamic imports? because workers not having to load unused modules significantly speeds things up (we're also working on some module registry improvements to gain even more from lazy loading)
smaller workers can also remain in memory for longer and be evicted less, generating less cold starts 🙂
no the monolith did not have dynamic imports, we had a custom terraform based deploy process where i webpacked that stuff myself, i dont know if wrangler cli could do build dry runs back then
and with that 1mb: i webpacked it REALLY good
we startet with free tier :D
ok that's interesting....
you not using dynamic imports there and splitting the logic across multiple workers definitely helps, but I am surprise you saw a huge different if your worker was < 1mb 🤔
ballpark, do you know the perf difference before and after?
i could measure it, we're currently in development of the new platform, but last i checked a simple user login took 100ms longer
but I am guessing that you did a bunch of code restructuring as well... so maybe even the busieness logic run for each request got lighter?
do you use any binding? (I am thinking of DO similar that can non-trivially impact perf)
it got even more complex because we have one platform for all of our tenants, when before we had one worker/db for each tenant
D1, Queues, R2, nothing complex like DO
dashboard isnt currently loading lol
🤯
R2 is also not distributed, and it's relatively slow, maybe that one is not only used by a subset of (slower) workers?
yeah from 18:00 here in germany to 21:00 cf dashboard is mostly unusable lol
mh.... it works for me... 🤔
r2 is only for reports that are beeing created daily and loaded on dashboard lookup, but that could be an impact with non dynamic imports
chrome btw
maybe try in incognito mode? (to make sure that there isn't something wrong with your browser such as cookies or cache)
nope
maybe it's telekom related lol
now* its working in both lol
yay 😄
(thats the monolith)
R2 operations and D1 writes are going to be more or less performant depending on the location, so if you now also have workers that don't use those those workers should be significantly faster
(what I am trying to say is that maybe R2 and/or D1 were possibly causing some bottlenecks?)
non-cached on the microservice-esq
could be
would make sense why now hyperdrive is much faster then before with the old api
the API service only makes requests to other microservices and not any db :D
another interesting thing is smart placement, if you have a single monolitic worker it can only, as a single unit be smart placed, but if you have multiple workers each could be smart placed which I believe could also really speed things up 😄
yeah and another thing is we are a Point of Sales Company, we do not benefit from smart placement with multiple monoliths because every customer has different usage patterns, with one central api gateway we have fewer cold starts and better smart placement, thats what i already figured out :D
btw thats why we shifted from D1, as POS Company we have highly sensitive data for the financial institutes here in germany, not that we dont trust cloudflare, but with an external postgres we have better data security and could shift away from CF if european law forces us to
I see 🙂
Well, thankfully hyperdrive helps you get nice perfs with your Germany db as well 😄
currently working with neon while developing, i hope our prod db will work as well ^^
and again, its insane what you guys are doing. im an advocate for sovereing cloud and non vendor locking, but DAMN cloudflare workers taste so damn good
nice! I'm glad to hear that 😄 🚀
Thanks for using our sevices 🫶
:MeowHeartCloudflare: