Datasync server performance #131
-
We are considering DS as a way to make our Maui mobile app perform well in a connectivity-challenged environment. One concern is the impact that these proactive REST requests might have on our database.... Let’s say.. At maximum, we expect 5,000 or so active users with the mobile app running on their phone at any given time. If we’re polling for data updates every 10 seconds, that would mean our web servers would need to handle 30,000 requests per minute. Does that mean that EF Core will perform 30,000 database queries per minute (one per request) as well? Or, is there some mechanism that EF Core uses to determine whether any changes have been made without making a database query? If not, is there a way we can modify our DS server integration to limit the query load on our DB? I found this blog post from @adrianhall describing how to implement data caching to avoid DB queries for Azure Mobile Apps. Does this still apply to Datasync? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Transferring to discussions. |
Beta Was this translation helpful? Give feedback.
-
Short version: DCT is not suitable for your use case. Use a real-time database like Couchbase, Microsoft Fabric, or GraphQL with Subscriptions (HotChocolate, for example) instead. Long polling is a bad idea. If you are dealing with every 10 seconds, that's way too short a time and you want to convert your app into a "real-time" functionality. At it's core that means that you have to establish a "change feed processor" for your database that feeds relevant changes to some sort of WebSocket or SignalR environment that your clients can watch. It's entirely event driven. There are multiple ways to do this - GraphQL with subscriptions (HotChocolate), CouchBase, Microsoft Fabric, among others. It's important to note here that the database must support it - if it doesn't, you are out of luck, MongoDB has Change Streams - which is a good start. Cosmos DB has a change feed as well. So these can be used as the basis. However, EF Core doesn't support change streams so you would need to "roll your own". That isn't to say that Datasync Community Toolkit can't be a part of the solution - just you would have to do so much more in order to make it work the way you want. And yes, my article on caching with API Management is still relevant, but I would ignore it for the purposes of your use case. |
Beta Was this translation helpful? Give feedback.
Short version: DCT is not suitable for your use case. Use a real-time database like Couchbase, Microsoft Fabric, or GraphQL with Subscriptions (HotChocolate, for example) instead.
Long polling is a bad idea. If you are dealing with every 10 seconds, that's way too short a time and you want to convert your app into a "real-time" functionality. At it's core that means that you have to establish a "change feed processor" for your database that feeds relevant changes to some sort of WebSocket or SignalR environment that your clients can watch. It's entirely event driven. There are multiple ways to do this - GraphQL with subscriptions (HotChocolate), CouchBase, Microsoft Fabric, among others. …