143 votes

Correction du chargement initial lent pour IIS

IIS a une fonction ennuyeuse pour les sites Web à faible trafic : il recycle les processus de travail inutilisés, ce qui entraîne un délai extrêmement long (plus de 30 secondes) pour le premier utilisateur du site après un certain temps.

J'ai cherché une solution au problème et j'ai trouvé ces solutions potentielles.

A. Utilisez le plugin d'initialisation de l'application

B. Utiliser le démarrage automatique avec .NET 4

C. Désactiver l'idle-timeout (sous IIS Reset)

D. Précompiler le site

Je me demande laquelle de ces solutions est préférable et, surtout, pourquoi il y a tant de solutions au même problème ? (Je pense qu'il n'y en a pas et que je ne comprends pas bien).

Modifier

Exécution C semble suffire à réchauffer mon site, mais j'ai découvert que la véritable racine de la lenteur de mon site est liée à Entity Framework, dont je ne parviens pas à comprendre pourquoi il se refroidit. Voir este question, qui malheureusement, il n'a pas encore été répondu a été répondu !

J'ai fini par faire un réchauffer le script pour visiter mon site de temps en temps pour s'assurer qu'il reste rapide.

40voto

Răzvan Panda Points 6800

Les options A, B et D semblent être dans la même catégorie puisqu'elles n'influencent que le temps de démarrage initial, elles font le réchauffement du site web comme la compilation et le chargement des bibliothèques en mémoire.

L'utilisation de C, en définissant le délai d'inactivité, devrait être suffisante pour que les demandes ultérieures au serveur soient servies rapidement (le redémarrage du pool d'applications prend un certain temps - de l'ordre de quelques secondes).

Pour autant que je sache, le délai d'attente existe pour économiser la mémoire dont d'autres sites Web fonctionnant en parallèle sur cette machine pourraient avoir besoin. Le prix à payer est un temps de chargement lent.

Outre le fait que le pool d'applications est arrêté en cas d'inactivité de l'utilisateur, le pool d'applications sera également recyclé par défaut toutes les 1740 minutes (29 heures).

De technet :

Les pools d'applications d'Internet Information Services (IIS) peuvent être périodiquement recyclés afin d'éviter les états instables qui peuvent conduire à des problèmes d'application. des applications, des blocages ou des fuites de mémoire.

Tant que le recyclage de l'app pool reste actif, cela devrait suffire. Mais si vous voulez vraiment des performances de pointe pour la plupart des composants, vous devriez également utiliser quelque chose comme le module d'initialisation d'application que vous avez mentionné.

10voto

daylight Points 329

Le défi de l'hébergement Web

Il ne faut pas oublier qu'aucune des options de configuration de la machine n'est disponible si vous êtes hébergé sur un serveur partagé, comme c'est le cas pour beaucoup d'entre nous (petites entreprises et particuliers).

Surcharge de l'ASP.NET MVC

Mon site prend au moins 30 secondes alors qu'il n'a pas été consulté depuis plus de 20 minutes (et que l'application web a été arrêtée). C'est terrible.

Une autre façon de tester les performances

Il y a un autre moyen de tester si c'est le démarrage de votre ASP.NET MVC ou quelque chose d'autre. Déposez une page HTML normale sur votre site où vous pouvez l'atteindre directement.
Si le problème est lié au démarrage d'ASP.NET MVC, la page HTML s'affiche presque immédiatement, même si l'application Web n'a pas été lancée.
C'est ainsi que j'ai compris que le problème se situait au niveau du démarrage d'ASP.NET MVC. Je chargeais une page HTML à tout moment et elle se chargeait très rapidement. Puis, après avoir cliqué sur cette page HTML, je cliquais sur l'une de mes URL ASP.NET MVC et j'obtenais le message Chrome "Waiting for raddev.us...".

Un autre test avec le script utile

Après cela, j'ai écrit un LINQPad (consultez la rubrique http://linqpad.net pour plus) script qui frappait mon site web toutes les 8 minutes (moins que le temps de déchargement de l'application -- qui devrait être de 20 minutes) et je l'ai laissé tourner pendant des heures.

Pendant que le script était en cours d'exécution, j'ai visité mon site web et à chaque fois, mon site s'est affiché très rapidement. Cela me donne une bonne idée que la lenteur que j'éprouvais était probablement due aux temps de démarrage d'ASP.NET MVC.

Obtenez LinqPad et vous pouvez exécuter le script suivant - changez simplement l'URL par la vôtre et laissez-le s'exécuter et vous pourrez tester cela facilement. Bonne chance.

NOTE : Dans LinqPad, vous devez appuyer sur F4 et ajoutez une référence à System.Net pour ajouter la bibliothèque qui récupérera votre page.

AUSSI : assurez-vous de modifier la variable String URL pour qu'elle pointe vers une URL qui chargera une route de votre site ASP.NET MVC afin que le moteur fonctionne.

System.Timers.Timer webKeepAlive = new System.Timers.Timer();
Int64 counter = 0;
void Main()
{
    webKeepAlive.Interval = 5000;
    webKeepAlive.Elapsed += WebKeepAlive_Elapsed;
    webKeepAlive.Start();
}

private void WebKeepAlive_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
    webKeepAlive.Stop();
    try
    {
        // ONLY the first time it retrieves the content it will print the string
        String finalHtml = GetWebContent();
        if (counter < 1)
        {
            Console.WriteLine(finalHtml);
        }
        counter++;
    }
    finally
    {
        webKeepAlive.Interval = 480000; // every 8 minutes
        webKeepAlive.Start();
    }
}

public String GetWebContent()
{
    try
    {
    String URL = "http://YOURURL.COM";
    WebRequest request = WebRequest.Create(URL);
    WebResponse response = request.GetResponse();
    Stream data = response.GetResponseStream();
    string html = String.Empty;
    using (StreamReader sr = new StreamReader(data))
    {
        html = sr.ReadToEnd();
    }
    Console.WriteLine (String.Format("{0} : success",DateTime.Now));
    return html;
    }
    catch (Exception ex)
    {
        Console.WriteLine (String.Format("{0} -- GetWebContent() : {1}",DateTime.Now,ex.Message));
        return "fail";
    }
}

3voto

David Chelliah Points 1120

L'écriture d'un service/script ping pour frapper votre site Web inactif est plutôt une meilleure façon de procéder car vous aurez un contrôle complet. Les autres options que vous avez mentionnées seraient disponibles si vous aviez loué un boîtier d'hébergement dédié.

Dans un espace d'hébergement partagé, les scripts d'échauffement sont la meilleure défense de premier niveau (l'auto-assistance est la meilleure aide). Voici un article qui partage un une idée sur la façon de le faire à partir de votre propre application web .

2voto

Kit Points 4632

J'utiliserais B parce que cela, en conjonction avec le recyclage du processus de travail, signifie qu'il n'y aurait qu'un retard pendant le recyclage. Cela évite le retard normalement associé à l'initialisation en réponse à la première demande après l'inactivité. Vous pouvez également conserver les avantages du recyclage.

2voto

Nuzzolilo Points 411

Consultez cet article pour obtenir des conseils sur la façon d'aider les problèmes de performance. Cela inclut les problèmes de performance liés au démarrage, dans la section "démarrage à froid". La plupart de ces conseils sont valables quel que soit le type de serveur que vous utilisez, en local ou en production.

https://blogs.msdn.microsoft.com/b/mcsuksoldev/2011/01/19/common-performance-issues-on-asp-net-web-sites/

Si l'application désérialise quoi que ce soit à partir de XML (et cela inclut les services web ), assurez-vous que SGEN est exécuté contre tous les binaires impliqués dans la désérialisation et placez les DLL résultantes dans le Global Assembly Cache (GAC). Cela précompile tous les objets de sérialisation utilisés par les assemblages sur lesquels SGEN a été exécuté et les met en cache dans la DLL résultante. Cela peut permettre un gain de temps considérable lors de la première désérialisation (chargement) des fichiers de configuration à partir du disque et des appels initiaux aux services Web. http://msdn.microsoft.com/en-us/library/bk3w6240(VS.80).aspx

Si les serveurs IIS n'ont pas d'accès sortant à Internet, désactivez la vérification de la liste de révocation des certificats (CRL) pour les binaires Authenticode en ajoutant generatePublisherEvidence="false" dans machine.config. Dans le cas contraire, tous les processus de travail peuvent se bloquer pendant plus de 20 secondes au démarrage pendant qu'ils essaient de se connecter à l'Internet pour obtenir une liste CRL. http://blogs.msdn.com/amolravande/archive/2008/07/20/startup-performance-disable-the-generatepublisherevidence-property.aspx

http://msdn.microsoft.com/en-us/library/bb629393.aspx

Envisagez d'utiliser le NGEN sur tous les assemblages. Cependant, sans une utilisation prudente, cela ne donne pas beaucoup de gain de performance. En effet, les adresses de chargement de base de tous les binaires qui sont chargés par chaque processus doivent être soigneusement définies au moment de la construction pour ne pas se chevaucher. Si les binaires doivent être repositionnés lorsqu'ils sont chargés à cause de conflits d'adresses, presque tous les gains de performance de l'utilisation de NGEN seront perdus. http://msdn.microsoft.com/en-us/magazine/cc163610.aspx

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X