Microsoft SharePoint 2010 : Profiler et empaqueter le code sandbox
En profilant et empaquetant correctement les solutions à exécuter dans un environnement sandbox, vous avez un meilleur contrôle de l'utilisation et de l'évolutivité des ressources.
C. Gnanasekaran
Lorsque vous générez une solution de Web d'entreprise basée sur SharePoint 2010, performance tuning et les tests est une partie importante du cycle de développement. Si votre solution contient beaucoup de code personnalisé, puis il n'est pas seulement important, qu'il est essentiel.
SharePoint vous offre plusieurs options de personnalisation, tels que les composants WebPart, les récepteurs personnalisés, des actions personnalisées et ainsi de suite. Vous avez également des options pour les modèles d'exécution différents pour vous donner un plus grand contrôle de performance, de sécurité et haute disponibilité. Une « solution sandbox » est un tel modèle d'exécution.
Vous pouvez créer un profil de performance des blocs de code que vous construire à exécuter dans un environnement sandbox à l'aide du profileur autonome de Visual Studio 2010. Un autre facteur important qui affectera les performances et l'évolutivité des solutions sandbox est la manière dont vous empaquetez et déployez des blocs de code personnalisés tels que des composants WebPart. Vous pouvez package de ces composants pour tirer parti des services de bac à sable s'exécutant sur plusieurs serveurs, notamment dans les batteries de serveurs enterprise-grade.
SharePoint 2010 a différents outils pour vous aider à identifier les goulots d'étranglement potentiels dans votre code personnalisé en enquêtant sur le temps pris pour l'exécution de code ; appels vers des ressources externes telles que les Web services, bases de données, les requêtes de base de données et nombre de fois où les requêtes sont déclenchés ; et ainsi de suite. Vous pouvez utiliser le tableau de bord développeur pour comprendre les blocs de code différents temps prennent à exécuter. Vous pouvez également analyser les temps d'exécution avec des journaux du Service de journalisation unifiée (ULS).
Certaines contraintes
Dans le cas des solutions de la Sablière, le tableau de bord développeur n'apportera aucune information utilisable. Aussi, il n'y aura aucune informations sur l'exécution sur la solution sandbox disponibles dans le journal ULS. Composants de sandbox ne sont pas autorisés à enregistrer des informations dans les journaux ULS. Parce que SharePoint 2010 ne vous aider à comprendre le comportement des blocs de code personnalisé dans un environnement sandbox, vous devrez compter sur les capacités de profils de Visual Studio Team System2010.
Lorsqu'il s'agit de profilage du code, vous avez essentiellement deux options : performance tester les modèles de projet dans Visual Studio 2010, ou à l'aide d'un profileur autonome de Visual Studio Team System. Si vous êtes performance tester les modèles de projet Visual Studio, vous devez définir votre code source avec toutes les dépendances nécessaires dans la même machine où Visual Studio Team System (VSTS) 20 Ultimate Edition est installée. Seulement, vous pourrez l'utiliser dans l'environnement de développement. Gardez à l'esprit qu'il n'est pas capturer les détails reliés à l'exécution de code dans un environnement sandbox, ni fonctionne-t-il avec les collections de sites d'en-tête hôte.
Si vous utilisez un profileur autonome de Visual Studio Team System, vous n'aurez pas besoin du code source. Il fonctionne avec la sortie compilée. Vous pouvez l'utiliser dans des environnements en amont — comme étape, utilisateur acceptation essais (UAT), près de la production et ainsi de suite — où installer les outils de développement n'est pas autorisé. Cette méthode vous offre également une certaine souplesse, donc vous pouvez profiler tous les processus en dehors de W3WP.exe. Cela vous aide à extraire les détails reliés à l'exécution de code dans un environnement sandbox en termes de mémoire et de temps d'exécution.
Dans le cas des blocs de code dans un environnement sandbox, la deuxième option fonctionne bien, car il vous donne la flexibilité de profil tout processus tel que requis. Dans le cas d'un profileur autonome, vous avez deux options :
- VSAspNetCmd.exe, qui est conçue pour profilage W3WP.exe exclusivement.
- VSPerfCmd.Exe, vous pouvez utiliser pour n'importe quel processus de profil.
Les rapports de que ces profileurs de génèrent la volonté vous donnent des informations plus détaillées que le tableau de bord développeur, y compris les informations de « niveau ». Il s'agit d'informations sur les demandes d'appel venant à travers les machines et les réseaux de ressources externes, telles que la solution sandbox de base de données.
Dans le cas de cette solution sandbox, vous pouvez utiliser deux options : L'exécution de l'ensemble du code dans un processus de bac à sable, ou à l'aide d'un proxy de confiance totale (hybride). Parfois, afin d'éviter les restrictions, le processus de la sandbox, vous devez exécuter le code dans un proxy de confiance totale. Dans les deux cas, l'exécution de code n'arrivera dans W3WP.exe, parce que c'est ce qui se passe dans des solutions axées sur la ferme, out-of-box et un code personnalisé. Donc, profilage W3WP.exe ne donnent aucun résultat pour les blocs de code de sandbox.
Selon l'option que vous choisissez, l'exécution de code pour la solution sandbox arrivera au SPUCWorkerProcess.exe ou SPUCWorkerProcessProxy.exe. Pour l'exécution de code de profil et comprendre le comportement du code, ces deux processus sont présentés selon le modèle choisi. Dans le cas d'un bac à sable, vous serez profil SPUCWorkerProcess.exe. Dans le cas de l'approche hybride à l'aide d'un proxy de confiance totale, vous serez profil SPUCWorkerProcessProxy.exe.
Comme « VSPerCMD.exe » est conçu pour tout processus requis de profil, vous pouvez l'utiliser pour le processus de SPUCWorkerProcess.exe et de SPUCWorkerProcessProxy.exe de profil. Vous obtiendrez ainsi des informations détaillées qui vous aideront à en apprendre davantage sur l'exécution de code dans un environnement sandbox en termes de mémoire et de temps d'exécution.
Profilage de Code Sandbox
Lorsque le profilage de code sandbox, vous avez deux options : l'échantillonnage et l'instrumentation. Échantillonnage vous donnera plus de détails à un niveau plus élevé. Instrumentation est préférable lorsque vous avez besoin d'une analyse approfondie. En règle générale, l'échantillonnage suffira pour exigences communes-profilage du code.
Voici la séquence de commandes nécessaire pour exécuter un profil. Tout d'abord, vous devez configurer les variables d'environnement nécessaires :
VSPerfClrEnv /globalsampleon
Redémarrez l'ordinateur, puis utilisez la commande suivante :
VSPerfClrEnv /globalinteractionon
La commande « globalsampleon » définit le profil pour effectuer le prélèvement. La commande « globalinteractionon » permet le profileur de recueillir l'information d'interaction de niveau. Après avoir défini les variables d'environnement, redémarrez la machine.
Le profileur n'est pas compatible en fournissant des informations de niveau. Donc lorsque les informations de niveau n'est pas disponibles, vous devez configurer ces variables et de redémarrer la machine. C'est le comportement naturel de la version actuelle du profiler.
Dans la prochaine étape après le redémarrage de la machine, mettre en place le profileur d'échantillonnage et le nom du fichier de sortie.
Démarrez l'application Web respectif. Identifier l'ID de processus du processus respectif pour que l'application — si plusieurs applications Web sont en cours d'exécution dans cette machine — puis appliquer le code suivant :
VSPerfCmd /Start:Sample /Output:<FILE_NAME>.vsp /user:everyone /CrossSession
Ensuite, repose sur le modèle d'exécution vous choisissez, identifier les « SPUCWorkerProcess.exe » ou « SPUCWorkerProcessProxy.exe » et le profileur seront attacher le processus choisi :
VSPerfCmd /Attach:<PROCESS-ID>
Effectuer des actions de l'utilisateur de cette application Web :
VSPerfCmd /Detach:<PROCESS-ID> VSPerfCmd /Shutdown
Si que vous devez relever les problèmes liés aux symboles, puis joindre ces symboles pour les rapports :
VSPerfReport.exe /summary:all /packsymbols <ReportName.VSP>
Enfin, réinitialiser les variables d'environnement :
vsperfclrenv /globaloff
Vous pouvez ouvrir les rapports que ce profileur génère dans Visual Studio 2010 Ultimate edition pour identifier les chemins de « chauds » et de comprendre le comportement de code dans un environnement sandbox. Cela aidera à prendre les mesures correctives appropriées pour optimiser les performances.
S'assurer que votre environnement de Visual Studio est configuré avec les symboles appropriés pour ouvrir le rapport sans perte d'information. Dans les machines de profileurs autonome installées avec une édition de Visual Studio 2010 (sauf ultime), vous pouvez rencontrer des erreurs. Il est conseillé d'installer uniquement les profileurs autonome.
Solution emballage
Lorsqu'il s'agit de solutions d'emballage sandbox, vous devez tenir compte des configurations de niveau. Rangées dans des solutions sandbox offrent un moyen de solutions sandbox de groupe basée sur les besoins en ressources. En configurant les niveaux à exécuter des processus plus, vous pouvez exécuter plus de solutions sandbox simultanément dans une ferme. Vous pouvez avoir un maximum de 20 processus de travail à travers tous les niveaux, sur un seul serveur.
Le nombre de connexions par processus doit être inférieur ou égal au nombre de domaines d'application. Ce nombre de connexions doit également être inférieure pour le niveau où la propriété « ResourceMaxValue » est définie à une valeur plus élevée.
Vous pouvez uniquement exécuter une solution sandbox dans chaque domaine d'application à tout moment. Le nombre de domaines d'application représente le nombre de solutions sandbox, que vous pouvez charger à tout moment. Un seul fichier WSP représente une solution sandbox. Après le téléchargement d'un paquet WSP, vous pouvez voir qu'il figure avec les autres solutions sandbox dans la Galerie de la solution.
Vous pouvez configurer des solutions sandbox en soit mode local ou distant. Vous devez utiliser mode distant dans les scénarios où la ferme a consacré des serveurs pour l'exécution de code carré de sable et de l'évolutivité.
Ainsi, si tous les composants WebPart et les blocs de code personnalisé sont emballés dans le cadre d'un package unique, ce paquet sera ensuite chargé dans un niveau dans un domaine d'application. Les autres domaines d'application demeurent au même niveau et ne servir, donc il n'y aura aucune répartition de la charge à travers des niveaux et des serveurs. Cela pourrait entraîner le rendement et les goulets d'étranglement évolutivité.
Blocs de code sandbox emballés à travers de multiples paquets donnera lieu à plusieurs solutions de sandbox. Les avantages de cette procédure sont les suivants :
- Ayant plusieurs solutions sandbox contribue à améliorer la surveillance de la ressource. Cela vous permet de réaliser quelle solution sandbox est élevée dans la consommation des ressources. Puis vous pouvez rechercher toute possibilité d'optimiser la consommation de ressources pour cette solution sandbox particulier. Ceci aide également avec le niveau de planification. Ayant tous les blocs de code de sandbox dans une solution unique ou un colis ne vous donnera tous les détails sur l'utilisation des ressources de WebPart particulier ou de blocs de code de sandbox.
- Vous pouvez créer une configuration de niveau basée sur l'utilisation des ressources moyenne des solutions individuelles sandbox, se traduira par une utilisation judicieuse des ressources serveur.
- Le processus de déploiement sera plus facile. WebPart individuels et les groupes peuvent être déployées ou mis à niveau facilement au lieu de déploiement de la solution ensemble pour fournir une mise à jour mineure pour un composant WebPart particulier.
Basé sur ces facteurs, il est préférable de regrouper logiquement WebPart et autres blocs de code à travers plusieurs packages de solution au lieu de leur emballage dans une solution sandbox unique. Code bon sandbox bloque emballage à travers différente solution colis contribuera à vous donner un aperçu une plus grande utilisation des ressources pour les blocs de code différents sandbox.
Une fois que vous avez une meilleure vue sur l'utilisation des ressources, vous pouvez utiliser l'exercice profilage pour identifier les zones potentielles d'amélioration dans les différentes parties des blocs de code (en termes de performances) et d'effectuer des activités d'optimisation de code. Vous pouvez également améliorer la performance, l'évolutivité et l'utilisation efficace des ressources.
.jpg)
C. Gnanasekaran a plus de 14 ans d'expérience comme TOGAF 9 Certified Enterprise Architect et Microsoft Consulting Services Inde, où il fournit des services de consultation architecturales aux clients. Ses domaines actuels de comprennent SharePoint, SQL Server OLAP/OLTP et Windows Azure. Il a publié des articles de technologie dans différentes revues dont The Architecture Journal et CodeProject. Blogs d'a à gnanasekaran.com.