Comment faire pour « réchauffer » Entity Framework ? Quand l’obtenir « à froid » ?

Question

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

Préface:

J'ai fait beaucoup de recherche sur Entity Framework récemment, et quelque chose qui retient dérange moi, c'est son exécution lorsque les requêtes ne sont pas réchauffé, alors en froid requêtes.

Je suis allé à travers les facteurs de performance de l'article pour Entity Framework 5.0. Les auteurs ont introduit la notion de Chaud et de Froid requêtes et comment ils diffèrent, que j'ai aussi remarqué moi-même, sans avoir connaissance de leur existence. Ici, c'est probablement la peine de mentionner, je n'ai que six mois d'expérience derrière mon dos.

Maintenant, je sais quels sont les sujets que je peux de la recherche dans de plus si je veux comprendre le cadre de mieux en termes de performances. Malheureusement, la plupart de l'information sur Internet est obsolète ou gonflé avec de la subjectivité, d'où mon incapacité à trouver des informations supplémentaires sur les Chaudes vs Froid requêtes sujet.

Fondamentalement, ce que j'ai remarqué jusqu'à présent, c'est que chaque fois que je dois recompiler ou le recyclage de frappe, mes premières requêtes sont très lents. Aucune autre donnée de la lecture est rapide (subjective), comme prévu.

Nous allons migrer vers Windows Server 2012, IIS8 et SQL Server 2012 et en Junior, j'ai gagné moi-même l'occasion de les tester avant le reste. Je suis très heureux, ils ont introduit un échauffement module qui vous permettra d'obtenir ma demande de prêt pour la première demande. Cependant, je ne suis pas sûr de savoir comment procéder avec le réchauffement mon Entity Framework.

Ce que je sais déjà en vaut la peine:

• Générer mon point de Vue à l'avance, comme l'a suggéré.
• Déplacer mes modèles dans une autre assemblée.

Ce que je envisager de le faire, en allant avec le sens commun, probablement une mauvaise approche:

• Faire factice des lectures de données au Démarrage de l'Application pour les réchauffer choses jusqu'à, générer et valider les modèles.

Questions:

• Quelle serait la meilleure approche à avoir de la haute disponibilité sur mon Entity Framework à tout moment?
• Dans ce cas, le Cadre de l'Entité qui se "à froid" de nouveau? (Recompilation, de Recyclage, de Redémarrer IIS, etc.)

Answer 1

• Quelle serait la meilleure approche à avoir de la haute disponibilité sur mon Entity Framework à tout moment?

Vous pouvez aller pour un mélange de préfabriqués vues statiques et les requêtes compilées.

Statique CompiledQuerys sont bons car ils sont rapides et faciles à écrire et aider à réduire les performances. Cependant, avec EF5 il n'est pas nécessaire de compiler toutes vos requêtes depuis EF compiler automatiquement les requêtes de lui-même. Le seul problème est que ces requêtes peuvent être perdus lorsque le cache est balayé. Si vous voulez continuer à contenir des références à vos propres requêtes compilées pour ceux qui ne se produisent que très rares, mais qui sont coûteux. Si vous mettez ces requêtes dans les classes statiques ils seront compilés lorsqu'ils sont d'abord nécessaires. Cela peut être trop tard pour certaines requêtes, de sorte que vous voudrez peut-être forcer la compilation de ces requêtes lors du démarrage de l'application.

Pregenerating points de vue est l'autre possibilité comme vous le mentionnez. En particulier, pour les requêtes qui prennent beaucoup de temps à compiler et qui ne changent pas. De cette façon, vous déplacez la charge de travail à partir d'exécution au moment de la compilation. Aussi, cela ne présenter aucun lag. Mais bien sûr, ce changement passe par la base de données, il n'est pas si facile à traiter. Le Code est plus souple.

Ne pas utiliser beaucoup de TPT héritage (c'est un général problème de performances EF). Ni construire votre hiérarchies d'héritage trop profond ni trop large. Seulement 2-3 propriétés spécifiques à une catégorie peut ne pas être suffisante pour nécessiter un propre, mais qui pourrait être traitée comme option (nullable) propriétés d'un type existant.

Ne pas se tenir à un contexte unique pour un long moment. Chaque instance de contexte a son propre premier niveau de cache ce qui ralentit les performances qu'il grandit. Création du contexte n'est pas cher, mais la gestion de l'état à l'intérieur de la mise en cache des entités du contexte peut devenir coûteux. Les autres caches (plan de requête et de métadonnées) sont partagées entre les contextes et mourir avec le domaine d'application.

Dans l'ensemble, assurez-vous d'allouer des contextes souvent et de les utiliser seulement pour un court laps de temps, que vous pouvez démarrer rapidement votre demande, que vous compilez les requêtes qui sont rarement utilisés et fournir des préfabriqués vues pour les requêtes qui sont critiques pour les performances et souvent utilisé.

• Dans ce cas, le Cadre de l'Entité qui se "à froid" de nouveau? (Recompilation, de Recyclage, de Redémarrer IIS, etc.)

Fondamentalement, chaque fois que vous perdez votre domaine d'application. IIS effectue redémarre à chaque 29 heures, de sorte que vous ne peut jamais garantir que vous aurez vos instances. Aussi après un certain temps d'activité le domaine d'application est également fermé. Vous devriez essayer de venir rapidement à nouveau. Peut-être vous pouvez faire de l'initialisation asynchrone (mais méfiez-vous de multi-threading). Vous pouvez utiliser les tâches planifiées qui appel mannequin pages de votre application quand il n'y a pas de demandes pour éviter que le domaine d'application de mourir, mais il finira par.

J'ai aussi assumer lorsque vous modifiez votre fichier de configuration ou modifier les assemblées, il va y avoir un redémarrage.

Answer 2

Si vous êtes à la recherche pour une performance maximale dans tous les appels que vous devriez considérer votre architecture soigneusement. Par exemple, il pourrait être logique de pré-cache souvent utilisé look-ups dans le serveur de la RAM lors du chargement de l'application jusqu'au lieu d'utiliser les appels de base de données à chaque requête. Cette technique permet de réduire au minimum le temps de réponse des applications les plus couramment utilisées des données. Cependant, vous devez vous assurer d'avoir un comportement correct de l'expiration de la politique ou de toujours vider le cache à chaque fois que des modifications sont apportées, qui affectent la mise en cache des données pour éviter les problèmes avec la concurrence.

En général, vous devriez vous efforcer de concevoir des architectures distribuées pour ne nécessiter IO base de données des demandes lors de la mis en cache localement information est périmée, ou doit être transactionnelle. Tout "sur le fil" de demande de données est normalement de 10 à 1 000 fois plus de temps pour récupérer de un local, dans la mémoire cache de récupération. Ce seul fait seul fait souvent des discussions sur la "froid par rapport à chaud des données" sans conséquence par rapport au local et à distance" problème de données.

Answer 3

Conseils généraux.

• Effectuer rigoureux de journalisation, y compris ce qui est accessible et demande du temps.
• Effectuer factice des demandes lors de l'initialisation de votre application à chaud démarrage très lent vous demande de ramasser de l'étape précédente.
• Ne vous embêtez pas à l'optimisation, à moins que c'est un vrai problème, communiquer avec le consommateur de l'application et demander. Obtenez à l'aise d'avoir un cycle de rétroaction continue si seulement de comprendre à quels besoins d'optimisation.

Maintenant, pour expliquer pourquoi mannequin demandes ne sont pas la bonne approche.

• Moins de Complexité - Vous sont l'échauffement, l'application d'une manière qui fonctionnera indépendamment des changements dans le cadre, et vous n'avez pas besoin de comprendre, éventuellement, funky Api/framework internes pour faire de la bonne façon.
• L'augmentation de la Couverture - Vous réchauffement toutes les couches de la mise en cache à la fois liées à la lenteur de la demande.

Pour expliquer quand un cache "à Froid".

Ce qui se passe à tous les niveaux de votre cadre que s'applique une cache, il y a une bonne description en haut de la page de performance.

• Quand jamais un cache doit être validé après un changement de potentiel que fait le cache rassis, cela pourrait être un délai d'attente ou plus intelligent (c'est à dire changer dans l'article mis en cache).
• Lorsqu'un élément de cache est supprimé, l'algorithme est décrite dans la section "Cache expulsion de l'algorithme" dans la performance de l'article lié, mais bref.
  • LFRU (Moins fréquemment utilisées récemment) cache sur le nombre d'accès et d'âge, avec une limite de 800 articles.

Les autres choses que vous avez mentionnées, plus précisément de la recompilation et le redémarrage de IIS effacer des parties ou de la totalité de la mémoire caches.

Answer 4

Comme vous l'avez dit, l'utilisation de "pré-vues" c'est vraiment tout ce que vous devez faire.

Extrait à partir de votre lien: "Lorsque les vues sont générés, ils sont également validées. À partir d'un point de vue des performances, la grande majorité du coût de vue de la génération, est en fait la validation des points de vue"

Cela signifie que la performance knock aura lieu lors de la génération du modèle d'assemblage. Votre objet de contexte sera alors sauter le "froid de la requête" et de rester sensible de la durée de l'objet de contexte du cycle de vie ainsi que la suite un nouvel objet contextes.

L'exécution de requêtes non pertinentes ne serviront à rien d'autre but que de consommer des ressources système.

Le raccourci ...

1. Passez tous de ce que le travail supplémentaire de pré-vues
2. Créez votre contexte de l'objet
3. Incendie au large de ce doux pertinence de la requête
4. Puis il suffit de garder une référence à votre contexte de l'objet pour la durée de votre processus (non recommandé).

Answer 5

Je n’ai aucune expérience dans ce cadre. Mais dans d’autres contextes, par exemple Solr, complètement factices lectures ne sera pas d’une grande utilité à moins que vous pouvez mettre en cache l’ensemble DB (ou index).

Une meilleure approche serait d’enregistrer les requêtes, extraire les plus plus fréquentes sur les journaux et les utiliser pour se réchauffer. Juste être sûr de ne pas enregistrer le requêtes d’échauffement ou les retirer les journaux avant de continuer.