Linq to SQL et données en temps réel

Question

J'ai une application qui doit constamment (toutes les 50ms), appeler à une action MVC, et ramasser/déposer des données. J'utilise Linq to SQL et MVC en raison de leur simplicité de mise en œuvre, et je sais qu'ils ne sont pas parfaits en termes de performances, mais cela fonctionne relativement bien, mais la meilleure vitesse que je peux obtenir avec mon approche actuelle est de 200ms (sans que les demandes ne se chevauchent).

Chaque appel au site va créer une nouvelle instance du datacontext, interroger/insérer et renvoyer ces données.

Existe-t-il un moyen d'avoir le datacontext statique, mais les changements de type "submitchange" toutes les 5 secondes, de sorte que je frappe plutôt une version en mémoire des données?

Edit:

Je construit une architecture complètement déconnectée qui contient toutes les mêmes propriétés et les objets de mon contexte, et je déclare statiquement cet objet sur Application_Start(), et sur toutes les demandes de X, un fil est spun pour attacher tous les objets déconnectés et le stocker dans la base de données.

Cela a réussi à réduire mon temps aller-retour seulement 100ms, une grande amélioration, mais il est seuil de manque de ce qu'il doit être pour « en temps réel »

Je reçois au niveau de micro-optimisation, mais je n'arrive pas à pousser plus vite.

Answer 1

DataContext est destiné à être créé chaque fois que vous allez à la base de données. Cela ne devrait pas être un goulot d'étranglement.

Si vous êtes préoccupé par la création coûteuse de connexions à la base de données, cela ne pose peut-être pas de problème. Il y a un petit sondage de connexion afin que les connexions soient réutilisées par les appels suivants.

Ce que vous pouvez faire pour améliorer les performances (je n'ai pas entendu dire que ce soit mauvais en ce moment) est de remplacer le SQL généré automatiquement par des procédures stockées. Vous économiserez un peu sur la reconstitution d'un plan d'exécution.

Answer 2

CompiledQuery peut vous aider avec les performances. Mais il ne sera jamais plus rapide que le classique ADO.NET. Si la performance est la principale préoccupation, tout ORM est un très mauvais choix.

Vous pouvez toujours les mélanger (Linq2SQL + ADO.NET) pour obtenir des performances optimales.

Answer 3

Je ne pense pas que la création d'un contexte LINQ/requête est votre goulot d'étranglement ici. Il y a une légère surcharge à l'utiliser (comme n'importe quel ORM), mais cela ne devrait pas être significatif à moins que vous ne créiez beaucoup de contextes et d'arbres de requêtes complexes.

Ma conjecture serait probablement que LINQ ne génère pas la requête que vous attendez. Il peut en fait générer un tas de requêtes si vous ne faites pas attention, et essayer d'aller chercher à partir de plusieurs tables. Si vous voulez savoir quelles requêtes il est en cours d'exécution, vous pouvez utiliser

context.Log = Console.Out; // Or some other stream 

Vous pouvez également utiliser l'excellent LINQPad pour essayer vos requêtes. Si ce n'est pas le problème, vous devez profiler votre code en utilisant un profileur, Personnellement, j'aime dotTrace.