Nous avons travaillé dans un test d'acceptation utilisateur (UAT) environnement qui, par rapport au développement, est mort lente.
C'est un environnement complexe à l'aide de FBA, SQL 2008, SSRS et étendue web applications accessibles sur internet en utilisant https, ainsi, il a été difficile à traquer la question.
Pour un client précédent, Nous avons utilisé des FBA avec un fournisseur de rôles LDAP (et le fournisseur d'appartenances). Un de mes collègues, beaucoup plus intelligent que j'ai, a déterminé que le « hors de la boîte" Fournisseur de rôle LDAP, lorsqu'il est utilisé dans cet environnement, n'a pas été mise à l'échelle bien. Pour résoudre ce problème pour que le client, il mis en place un système de mise en cache sympa dans un fournisseur de rôles personnalisé.
Cette situation semblait similaire, alors nous avons regardé en répliquant cette solution client actuel. Comme j'étais débogage qui, J'ai remarqué que ce message apparaît fréquemment dans le journal système (de l'observateur d'événements):
Un processus de travail avec l'id de processus de ' XXX’ servant le pool d'application ' Accueil – 80’ a demandé un nouveau cycle car il a atteint sa limite de mémoire virtuelle.
J'ai pris cela pour signifier que le pool d'applications était loin recyclage, bien trop souvent et qui expliquerait un problème de performance.
J'ai regardé les propriétés du pool de l'app et son recyclage"" page a montré que la propriété « Maximum, mémoire virtuelle (en mégaoctets)" avait été défini true et avait été 5000. Cela semble assez semblables, mais j'ai décidé d'enlever la valeur et qui ont eu un effet positif immédiat. Pas plus de piscine app recyclage. Pas plus mystérieux des ralentissements et des pauses.
Je ne comprends pas vraiment les trucs"sous-jacente" qui se passe là-bas, mais clairement une sorte de chose de cause à effet qui se passe et pour l'instant, l'environnement UAT est utilisable.
</fin>
Phil Wicklund