Correction de la charge initiale lente pour IIS


129

IIS a une fonctionnalité ennuyeuse pour les sites Web à faible trafic où il recycle les processus de travail inutilisés, ce qui oblige le premier utilisateur sur le site après un certain temps à obtenir un délai extrêmement long (plus de 30 secondes).

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

A. Utilisez le plugin d'initialisation d'application

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

C. Désactiver le délai d' inactivité de (sous IIS Réinitialiser)

D. Précompiler le site

Je me demande laquelle de ces solutions est préférée et, plus important encore, pourquoi y a-t-il autant de solutions au même problème? (Je suppose qu'ils ne le sont pas, et je ne comprends tout simplement pas quelque chose correctement).

Éditer

L'exécution de C semble être suffisante pour garder mon site au chaud, mais j'ai découvert que la véritable racine de la lenteur de mon site est liée à Entity Framework, dont je n'arrive pas à comprendre pourquoi il fait froid. Voir cette question, qui n'a malheureusement pas encore reçu de réponse!

J'ai finalement dû créer un script d' échauffement pour accéder occasionnellement à mon site afin de m'assurer qu'il restait rapide.


Salut ami, est-ce que Performing C est suffisant? Pourquoi ? Avons-nous seulement besoin de l'utiliser ou avons-nous également besoin de désactiver recyclé? Je sens toujours que le deuxième jour, la première demande, est très lent de IIS7.5
qakmak

Réponses:


36

Les options A, B et D semblent être dans la même catégorie puisqu'elles n'influencent que l'heure de début initiale, elles font le préchauffage du site Web comme la compilation et le chargement des bibliothèques en mémoire.

L'utilisation de C, la définition du 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).

Autant que je sache, le délai d'expiration existe pour économiser la mémoire dont d'autres sites Web fonctionnant en parallèle sur cette machine pourraient avoir besoin. Le prix étant ce temps de chargement lent une fois.

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 IIS (Internet Information Services) peuvent être périodiquement recyclés pour éviter les états instables qui peuvent entraîner des pannes, des blocages ou des fuites de mémoire d'application.

Tant que le recyclage du pool d'applications est activé, cela devrait suffire. Mais si vous voulez vraiment des performances de premier ordre pour la plupart des composants, vous devez également utiliser quelque chose comme le module d'initialisation d'application que vous avez mentionné.


Alors recommanderiez-vous simplement de désactiver le délai d'inactivité? Cela causerait-il des problèmes le long de la ligne (je suppose que c'est là pour une raison)?
Cavyn VonDeylen

3
Cela ne résout pas vraiment mon problème (voir ma modification), mais j'ai accepté puisque vous avez répondu à ma question initiale.
Cavyn VonDeylen

10

Défi d'hébergement Web

Vous devez vous rappeler qu'aucune des options de configuration de la machine n'est disponible si vous êtes hébergé sur un serveur partagé comme beaucoup d'entre nous (petites entreprises et particuliers) le sont.

Frais généraux ASP.NET MVC

Mon site prend au moins 30 secondes lorsqu'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 existe un autre moyen de tester s'il s'agit de votre démarrage ASP.NET MVC ou de quelque chose d'autre. Déposez une page HTML normale sur votre site où vous pouvez la consulter directement.
Si le problème est lié au démarrage d'ASP.NET MVC, la page HTML s'affichera presque immédiatement même lorsque l'application Web n'a pas été démarrée.
C'est ainsi que j'ai reconnu pour la première fois que le problème était au démarrage d'ASP.NET MVC. J'ai chargé une page HTML à tout moment et elle se chargerait très rapidement. Ensuite, après avoir frappé cette page HTML, j'ai frappé l'une de mes URL ASP.NET MVC et j'obtiens le message Chrome "En attente de raddev.us ..."

Un autre test avec un script utile

Après cela, j'ai écrit un script LINQPad (consultez http://linqpad.net pour plus d'informations) qui frapperait mon site Web toutes les 8 minutes (moins que le temps de déchargement de l'application - ce qui devrait être de 20 minutes) et je laisse il a fonctionné pendant des heures.

Pendant que le script était en cours d'exécution, j'ai frappé mon site Web et chaque fois que mon site est apparu d'une vitesse fulgurante. Cela me donne une bonne idée que la lenteur que je rencontrais é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 et laissez-la s'exécuter et vous pouvez le tester facilement. Bonne chance.

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

AUSSI : assurez-vous de modifier la variable URL de chaîne pour qu'elle pointe vers une URL qui chargera une route à partir de votre site ASP.NET MVC afin que le moteur s'exécute.

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";
    }
}

3

Ecrire un service / script de ping pour accéder à votre site Web inactif est plutôt une meilleure façon de procéder car vous aurez un contrôle complet. D'autres options que vous avez mentionnées seraient disponibles si vous avez loué une boîte d'hébergement dédiée.

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


vient de mettre à jour cet ancien fil, au cas où quelqu'un chercherait le même
David Chelliah

2

J'utiliserais B car cela, associé au recyclage des processus de travail, signifie qu'il n'y aurait qu'un délai pendant le recyclage. Cela évite le délai normalement associé à l'initialisation en réponse à la première demande après l'inactivité. Vous bénéficiez également des avantages du recyclage.


2

Une bonne option pour envoyer une requête ping au site selon un calendrier est d'utiliser Microsoft Flow, qui est gratuit jusqu'à 750 "exécutions" par mois. Il est très facile de créer un flux qui frappe votre site toutes les heures pour le garder au chaud. Vous pouvez même contourner leur limite de 750 en créant un flux unique avec des délais séparant plusieurs visites de votre site.

https://flow.microsoft.com


1

Consultez cet article pour obtenir des conseils sur la façon de résoudre les problèmes de performances. Cela inclut les deux problèmes de performances liés au démarrage, dans la section «démarrage à froid». La plupart de ces éléments importeront quel que soit le type de serveur que vous utilisez, localement ou en production.

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

Si l'application désérialise quoi que ce soit de XML (et qui inclut des services Web…), assurez-vous que SGEN est exécuté sur 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 assemblys sur lesquels SGEN a été exécuté et les met en cache dans la DLL résultante. Cela peut permettre de gagner énormément de temps 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 des serveurs IIS n'ont pas d'accès sortant à Internet, désactivez la vérification de la liste de révocation de certificats (CRL) pour les binaires Authenticode en ajoutant generatePublisherEvidence = ”false” dans machine.config. Sinon, tous les processus de travail peuvent se bloquer pendant plus de 20 secondes lors du démarrage pendant que le délai de connexion à Internet pour obtenir une liste CRL expire. 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 NGEN sur tous les assemblages. Cependant, sans une utilisation prudente, cela ne donne pas beaucoup de gain de performance. Cela est dû au fait que les adresses de charge de base de tous les binaires chargés par chaque processus doivent être soigneusement définies au moment de la génération pour ne pas se chevaucher. Si les binaires doivent être rebasés lors de leur chargement en raison de conflits d'adresses, presque tous les gains de performances liés à l'utilisation de NGEN seront perdus. http://msdn.microsoft.com/en-us/magazine/cc163610.aspx


0

J'obtenais un délai constant de 15 secondes sur la première demande après 4 minutes d'inactivité. Mon problème était que mon application utilisait l'authentification intégrée de Windows sur SQL Server et que le profil de service était dans un domaine différent de celui du serveur. Cela a provoqué une authentification inter-domaines d'IIS vers SQL lors de l'initialisation de l'application - et c'était la véritable source de mon retard. J'ai changé pour utiliser une connexion SQL au lieu de l'authentification Windows. Le retard avait immédiatement disparu. J'ai toujours tous les paramètres d'initialisation de l'application en place pour améliorer les performances, mais ils n'ont peut-être pas du tout été nécessaires dans mon cas.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.