J'ai lu de nombreux articles sur LINQ à SQL Performance. Le résultat que j'ai obtenu est qu'il est plus lent que l'approche normale (bibliothèque DAL ou Microsoft Enterprise). plus lentement pour les opérations de lecture et d'écriture même après le réglage de la performance comme Désactiver l'objet d'objet et d'autres astuces. Je sais que cela a des prons comme le développement rapide, le code de nettoyage, etc., mais qu'en est-il de la performance.
Et si je n'utilisais que pour des opérations de lecture.
S'il vous plaît donner vos suggestions.
3 Réponses :
Pour les opérations de lecture LINQ to SQL doit être approximativement aussi rapide que d'écrire directement le SQL car c'est exactement ce qu'il fait. Les frais généraux de la création du SQL ne devraient pas être notifiables. Il pourrait y avoir quelques questions qui ne sont pas aussi optimales que si vous écrivez la requête à la main, mais dans mon expérience, cela fait très bien dans la plupart des cas.
Pour les mises à jour en vrac, LINQ to SQL est généralement plus lente car elle gère les rangées une à la fois. Vous ne pouvez pas faire quelque chose comme update foo set x = 0 où identifiant entre 100 et 200 à Linq sur SQL sans récupérer toutes les lignes. Il est actuellement préférable d'écrire le SQL à la main pour ce type d'opération.
Il semble fonctionner assez bien pour Stackoverflow ;-P surtout si vous utilisez requêtes compilées , il est peu probable que ce soit votre goulot d'étranglement, comparé (par exemple) à la conception DB appropriée et à récupérer les bonnes colonnes / lignes et en évitant le chargement N + 1.
@Gravel && @byers. une question. Supposons que nous ayons 3 serveurs. 1 Pour lire, 1 pour écrire et l'autre est un serveur de réplication. Donc, si j'utilise Linq pour des opérations de lecture et pour l'opération d'écriture, j'utilise des requêtes à la main. Est-ce la meilleure solution? ou y a-t-il une autre meilleure solution? ce que vous suggérez
@Adeel - Serveurs DB ou serveurs d'applications? On dirait que vous voulez dire que le serveur DB - mais je ne suis pas sûr que l'API spécifique API d'accès aux données utilisée va faire une énorme différence (par rapport aux différentes configurations de DB).
@Gravel Server signifie serveur de base de données. Comme l'approche LINQ est très lente pour les opérations d'écriture par rapport à l'API d'accès aux données, alors que la lecture de la performance est négligeable. Il est donc préférable d'utiliser Linq à des fins de lecture seulement?
@Adeel - c'est certainement meilleur en lecture que d'écrire; Cela dépend vraiment du scénario, cependant; La plupart des codes ne publient pas de grandes quantités de DML. Si vous DO avez-les, alors la commande de commandes est souhaitable, mais vous pouvez également envisager de tirer les données à la DB en vrac (par exemple XML ou SQLBulkCopy, ou dans les paramètres de valorisation de table SQL 2008) et Traitez-le à l'aide de mises à jour / insertions basées sur ensemble à la DB. Seuls les premiers d'entre eux sont disponibles via L2S.
@Adel: Cela dépend des requêtes spécifiques que vous devez faire. J'essaierais probablement de mesurer la performance réelle avec Linq d'abord avant de l'abandonner et de choisir une technologie différente. Il y a de nombreuses situations où elle fonctionnera bien pour lire et écrire. Mais vous dites que vous l'avez déjà mesuré et que vous l'avez trouvée considérablement plus lente. Je vérifierais probablement les requêtes qui envoient-ils en réalité à la DB pour voir s'il y a un problème évident avec une solution facile et effectuer des performances de la mesure pour voir où le temps est perdu, mais sinon, je pense que vous avez déjà votre Répondez là-bas.
@Adel: Je suggérerais d'utiliser SQLBulkCopy, comme suggéré par Marc, ainsi que d'essayer la mise en œuvre de la mise à jour par lots / supprimer que j'ai liée à la mise en place de leurs performances. Sans essayer, je suis d'accord avec Mark qu'il serait trop tôt pour abandonner. En fait, je suis sur le point de mettre en œuvre cela à mes propres objectifs de mesure mais je ne l'ai pas encore abordé, je n'ai donc aucun chiffre à partager. Néanmoins, je serais surpris si la performance ne s'est pas améliorée après la rétrécissement de la rétrécissement jusqu'à une requête.
Les mises à jour et les suppresses sont où LINQ to SQL souffre actuellement depuis une instruction distincte est générée pour chaque objet affecté.
Cela dit, ce blog post détaille comment obtenir les deux opérations jusqu'à 1 déclaration, ce qui devrait aider à améliorer les performances: Batch mises à jour et supprime avec LINQ à SQL .
Les requêtes compilées seront également utiles pour les requêtes fréquemment utilisées, en particulier celles où les paramètres sont utilisés pour obtenir des résultats spécifiques. Vous pouvez également trouver ce post utile: 10 conseils pour améliorer votre performance d'application LINQ à SQL .
+1 Je ne pense pas que sa linq à SQL soit un tout, mais plutôt le fait que c'est si profond, et si facile à faire mal. Un usage incompris d'une propriété de collection dans une boucle peut entraîner rapidement des problèmes de performances.