Replies: 2 comments
-
|
This is a very good question for Lombiq guys because they have a DotNest which contains a lot of tenants, if I'm wrong, I hope to hear from their experience |
Beta Was this translation helpful? Give feedback.
-
|
In a multi-tenant app, the first request wakes up a given tenant, after which it keeps running and thus consuming some resources (to keep its DI container in memory, run background tasks). If you have multiple deployments (I assume you use this in the server instance/node sense, i.e. instances of the app running in parallel) with a load balancer in front of them, then tenants will be woken up in the given deployment when their first request hits it. So you can eventually end up all the tenants running on all deployments. If you want to optimize this, then you need something that JT, RIP, started here: #13633. Or otherwise, you need to distribute requests to different tenants in a way that resourece usage evens out (which might not mean that X tenants are running in each deployments, since one tenant can have a lot more traffic than others). Also check out: https://dotnest.com/knowledge-base/topics/lombiq-hosting-suite. This is how we run ~600 OC tenants on DotNest (on Azure App Services). One of our modules can also put inactive tenants to sleep. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I'm studying best practices regarding Orchard Core in Kubernetes deployment (100+ tenants, being "independent sites with diferent URLs" for example).
Lots of deployments with few tenants? Or few deployments with lots of tenants?
There's some guide or advisory with this kind of analysis? Orchard specific metrics to look at?
Looking as a SRE analysis, with some tenants having huge access daily, while others not so constantly but they could have as a peak access (so autoscaling it's very important). If a peak access happen, then it instance must scale quickly as many instances is needed to grant access, and also very important, understand that the peak access has gone and unscale the instances not needed.
For my experience, latest deployments of Orchard in IIS, some tenants was running alone in one deployment, while other deployments group some tenants, so our team is studing the best approach to maximize Kubernetes scaling to manage elastic access during the day with instances as needed.
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions