[Asp.net] Comment "réchauffer" Entity Framework? Quand est-ce que ça devient "froid"?


Answers

Si vous recherchez une performance maximale pour tous les appels, vous devriez considérer votre architecture avec soin. Par exemple, il peut être judicieux de pré-mettre en antémémoire les recherches souvent utilisées dans la RAM du serveur lorsque l'application se charge au lieu d'utiliser les appels de base de données à chaque requête. Cette technique assurera des temps de réponse d'application minimum pour les données couramment utilisées. Cependant, vous devez vous assurer d'avoir une bonne politique d'expiration ou de toujours effacer votre cache à chaque modification apportée aux données mises en cache pour éviter les problèmes de concurrence.

En général, vous devez vous efforcer de concevoir des architectures distribuées qui ne requièrent que des requêtes de données basées sur les E / S lorsque les informations mises en cache localement deviennent obsolètes ou doivent être transactionnelles. Toute requête de données "over the wire" prendra normalement 10 à 1000 fois plus de temps pour être récupérée qu'une récupération locale du cache mémoire. Ce seul fait rend souvent les discussions sur les données «froides vs chaudes» sans conséquence par rapport à la question des données «locales vs distantes».

Question

Non, la réponse à ma deuxième question n'est pas l'hiver.

Préface:

J'ai fait beaucoup de recherches sur Entity Framework récemment et quelque chose qui ne cesse de me déranger est sa performance lorsque les requêtes ne sont pas réchauffées, ce qu'on appelle des requêtes froides.

J'ai parcouru l'article sur les considérations de performances pour Entity Framework 5.0. Les auteurs ont introduit le concept de requêtes Chaud et Froid et comment ils diffèrent, que j'ai aussi remarqué moi-même sans connaître leur existence. Ici, il est probablement utile de mentionner que j'ai seulement six mois d'expérience derrière mon dos.

Maintenant je sais quels sujets je peux rechercher en outre si je veux mieux comprendre le cadre en termes de représentation. Malheureusement, la plupart des informations sur Internet sont obsolètes ou saturées de subjectivité, d'où mon incapacité à trouver des informations supplémentaires sur le sujet des requêtes Warm vs Cold .

Fondamentalement, ce que j'ai remarqué jusqu'à présent, c'est que chaque fois que je dois recompiler ou que le recyclage se produit, mes requêtes initiales deviennent très lentes. Toute lecture ultérieure est rapide ( subjective ), comme prévu.

Nous migrerons vers Windows Server 2012, IIS8 et SQL Server 2012 et en tant que Junior, j'ai en fait eu l'opportunité de les tester avant le reste. Je suis très heureux qu'ils aient introduit un module d'échauffement qui préparera ma demande pour cette première demande. Cependant, je ne suis pas sûr de savoir comment procéder pour réchauffer mon Entity Framework.

Ce que je sais déjà vaut la peine d'être fait:

  • Générer mes vues à l'avance comme suggéré.
  • Déplacez éventuellement mes modèles dans un assemblage séparé.

Ce que je considère faire, en faisant preuve de bon sens, est probablement une mauvaise approche :

  • Faire des données factices se lit au démarrage de l'application afin de réchauffer les choses, générer et valider les modèles.

Des questions:

  • Quelle serait la meilleure approche pour avoir une haute disponibilité sur mon Entity Framework à tout moment?
  • Dans quels cas le Entity Framework redevient-il «froid»? (Recompilation, Recyclage, Redémarrage d'IIS etc.)



Comme vous l'avez dit, utilisez des «vues pré-générées», c'est tout ce que vous devez faire.

Extrait de votre lien : "Lorsque les vues sont générées, elles sont également validées Du point de vue des performances, la grande majorité du coût de génération des vues est en réalité la validation des vues"

Cela signifie que le cliquetis de performance aura lieu lorsque vous construisez votre assemblage de modèle. Votre objet contextuel ignore alors la "requête froide" et reste réactif pendant toute la durée du cycle de vie de l'objet de contexte ainsi que dans les nouveaux contextes d'objet suivants.

L'exécution de requêtes non pertinentes n'aura d'autre but que de consommer des ressources système.

Le raccourci ...

  1. Passer tout ce travail supplémentaire de vues pré-générées
  2. Créez votre contexte d'objet
  3. Lancez cette requête douce et non pertinente
  4. Ensuite, gardez juste une référence à votre contexte d'objet pour la durée de votre processus (non recommandé).