Fermer

décembre 26, 2019

Optimisations des performances dans la version Sitefinity 12.2


Rejoignez-nous pour une plongée en profondeur dans les détails des améliorations de performances dans Sitefinity 12.2. Découvrez ce que nous avons optimisé et combien de temps il peut économiser pour les tâches que vous effectuez chaque jour.

Sitefinity 12.2 propose un large éventail de nouvelles fonctionnalités qui rendent les spécialistes du marketing, les éditeurs de contenu et les développeurs plus productifs. L'équipe d'ingénierie Sitefinity se soucie profondément des performances des produits. Nous suivons et testons régulièrement les régressions de performances et nous résolvons les problèmes détectés au cours du cycle de développement normal.

Certaines modifications de code sont faciles d'un point de vue technique – de minuscules changements isolés avec un faible potentiel de régression peuvent augmenter les performances du produit lorsqu'ils ciblent les goulots d'étranglement de performances appropriés. Cependant, la résolution de certains problèmes de performances nécessite une approche plus globale et apporte des changements de code substantiels avec un potentiel de régression associé. Pour cela, nous avons dû approfondir tous les aspects du système pour identifier les goulots d'étranglement des performances et les zones précises du code qui pourraient être améliorées pour des scénarios utilisateur cruciaux.

Nous avons fourni deux types d'améliorations. Tout d'abord, nous avons ciblé les opérations de longue durée, comme le démarrage d'une instance Sitefinity. Vous constaterez ces changements immédiatement. Deuxièmement, nous avons modifié les opérations courantes utilisées dans l'ensemble de la base de code Sitefinity. Dans ce cas, les accélérations individuelles sont plus petites en valeurs absolues, mais les améliorations composées sont perceptibles en raison de la nature répétitive de ces opérations. Grâce à ces modifications, nous avons globalement rendu Sitefinity plus rapide.

Dans cet article de blog, vous trouverez des détails sur les améliorations de performances les plus importantes que nous ayons développées.

Temps de démarrage

Vous bénéficierez de ces améliorations principalement pendant le développement où les opérations de génération et de démarrage sont fréquentes, ainsi que dans les cas de redémarrage des applications dans les environnements de production.

Nous avons mesuré le temps de démarrage comme le temps nécessaire. Sitefinity à initialiser, sans prendre en compte le temps nécessaire au framework .NET pour démarrer l'application et à Sitefinity pour charger la demande de première page après l'initialisation.

Démarrage moyen dans différents environnements amélioré entre 9 et 25% [19659010] Configuration

Temps avant

Temps après

Réduction du temps

Projet de démonstration quantique – Azure App Service (P1V2)

47,95 s

35,74 s

25% [19659014] Projet de démonstration quantique – Azure App Service (P2V2)

26,58 s
            

22,65 s
            

15%

Projet de démonstration quantique – Azure App Service (P3V2)

25,09 s

21,93 s

13%

Projet client – Azure App Service (P1V2 )

40,17 s
            

32,58 s
            

19%

Projet client – Azure App Service (P2V2)

25,68 s
            

20,82 s
            

19%

Projet client – Azure App Service (P3V2)

23,90 s
            

20,42 s
            

15%

Machine locale – Intel Xeon E3-1246v3 3,5 GHz et SSD

14,5 s
            

13,2 s
            

9%

Sitefinity 12.2 dessert le contenu plus rapidement — Amélioration du temps de réponse du serveur

Vous verrez l'impact de ces améliorations lorsque les modifications de contenu invalident le cache de sortie, ainsi que lorsque le cache de sortie expire de lui-même, pour par exemple, avec le profil de cache standard qui a une expiration de deux minutes.

Nous avons mesuré le temps de réponse du serveur comme le temps jusqu'au premier octet (TTFB) sans cache de sortie. Nous avons pris les résultats en moyenne entre plusieurs pages différentes de chaque site Web. Les résultats ne mesurent pas non plus le premier chargement d'une page, ce qui peut inclure la compilation et le chargement d'objets dans le cache.

Moyenne Temps de réponse du serveur (TTFB) pour Pages dans différents environnements Amélioration de 14 à 31%

Configuration

Temps avant

Temps après

Réduction du temps [19659051] Projet de démonstration quantique – Azure App Service (P3V2)

0,52 s

0,36 s

31%

Quantum Demo Project – Azure App Service (P1V2)

0,53 s

0,37 s

30%

Projet client – Azure App Service (P1V2)

1,04 s

0,73 s

30%

Projet de démonstration quantique – Azure App Service (P2V2)

0,47 s

0,38 s

20%

Projet client – Azure App Service (P3V2)

0,90 s

0,76 s

16%

Projet client – Azure App Service (P3V2)

0,94 s

0,79 s

15%

Machine locale – Intel Xeon E3-1246v3 3,5 GHz et SSD

0,121 s

0,104 s

14%

Nouvelle heure de premier chargement de l'interface utilisateur (en utilisant l'écran Pages )

Vous bénéficierez de temps de chargement améliorés de l'écran Pages pour une première utilisation après l'initialisation de Sitefinity et chargement ultérieur. Cette modification affecte uniquement l'interface utilisateur repensée.

Nous avons mesuré le temps de chargement de l'interface utilisateur repensée une fois l'initialisation de Sitefinity terminée à l'aide de l'écran Pages .

Nouveau temps de premier chargement de l'interface utilisateur (en utilisant l'écran Pages ) dans différents environnements Amélioré entre 67 et 83%

Configuration

Temps avant

Temps après

Réduction du temps

Projet de démonstration quantique – Azure App Service (P1V2)

23,46 s

3,90 s

83%

Projet de démonstration Quantum –

Azure App Service (P2V2)

16,48 s [19659061] 3,37 s

80%

Projet de démonstration quantique –

Azure App Service (P3V2)

16,78 s

3,22 s

81%

Projet client – Azure App Service (P1V2)

21,00 s

4,88 s

77%

Projet client – Azure App Service (P2V2)

15,00 s

4,52 s

70%

Projet client – Azure App Service (P3V2)

14,83 s

4,89 s

67%

Machine locale – Intel Xeon E3-1246v3 3,5 GHz et SSD [19659060] 8,10 s

2,70 s [19659062] 67%

Optimisations des performances au démarrage

Nous avons identifié divers points chauds lors du démarrage du système. Nous avons abordé le problème de manière holistique et travaillé sur l'amélioration des chemins chauds dans les couches de code inférieures. Certains sont liés à la logique et aux méthodes spécifiques que nous avons introduites pour vous aider à personnaliser facilement les widgets MVC. Avec Sitefinity 12.2, nous proposons diverses optimisations, dont certaines sont configurables via de nouveaux paramètres. Vous pouvez décider si vous souhaitez que ces paramètres soient activés ou non.

Utiliser les assemblages de conteneurs de contrôleur mis en cache

Nous avons amélioré le démarrage de Sitefinity en modifiant la façon dont le système charge les assemblages avec les contrôleurs Feather au démarrage.

Nous avons introduit un nouvelle façon de récupérer ControllerContainerAttribute et ResourcePackageAttribute . Un nouveau paramètre contrôle cela, situé dans Paramètres -> Avancé -> Plume -> Utiliser des assemblages de conteneurs de contrôleur mis en cache . Étant donné que cette modification n'affecte pas l'expérience de l'utilisateur final, ce paramètre est activé par défaut dans Sitefinity 12.2. Cette modification s'applique aux projets nouvellement créés et mis à niveau.

Dans les versions précédentes, il y avait une surcharge de performances car Sitefinity chargeait tous les assemblages un par un au démarrage. Dans Sitefinity 12.2, nous avons ajouté une action post-génération qui génère un fichier JSON décrivant les assemblages Feather. Cela signifie que lorsque les clients génèrent le projet SitefinityWebApp un script s'exécute, recherche ces attributs et écrit les noms des assemblys dans un fichier JSON dans le répertoire bin. Si vous avez activé le paramètre, lorsqu'un projet Sitefinity démarre, il charge uniquement les assemblys décrits dans le fichier JSON au lieu de charger tous les assemblys dans le dossier bin.

Charger automatiquement les extensions Ninject

Nous avons introduit un nouveau «Charger automatiquement les extensions Ninject». Avec lui, vous pouvez contrôler le chargement automatique des extensions Ninject. Vous pouvez trouver ce paramètre dans Paramètres -> Avancé -> Plume .

Le système recherchera et chargera des modules Ninject personnalisés au démarrage uniquement si vous activez ce paramètre. En désactivant ce paramètre, vous pouvez considérablement augmenter le démarrage. Par exemple, dans Azure App Service P1V2 la recherche d'extensions Ninject peut prendre environ 10 secondes – ouch!

Ce paramètre est activé dans Sitefinity 12.2 . Cela signifie que vos projets fonctionneront comme avant la mise à niveau. Cependant, pensez à désactiver ce paramètre si vous n'utilisez pas d'extensions Ninject dans vos projets.

Test

Délai avant

Délai après

Réduction du temps

Démarrez Quantum dans Azure

00: 01: 18.73

00: 01: 04.90

18%

Chargement parallèle des modules Sitefinity

Depuis cette version, les modules Sitefinity sont chargés en parallèle au démarrage du système. De cette façon, tous les modules peuvent se charger simultanément, et ils n'attendent pas que l'un se termine pour commencer à charger l'autre. Cette amélioration est très importante car le temps total de chargement de tous les modules est réduit au temps nécessaire pour charger le module le plus lent.

Test

Temps avant

Temps après

Réduction du temps

Modules parallèles chargement

00: 00: 03.55

00: 00: 01.72

52%

Feather File Monitor Initialization Optimization

Ce changement contribue à une diminution considérable du temps de démarrage.

Nous avons réduit la DB interroge le Feather FileMonitorInitializer lors du démarrage jusqu'à un seul.

Test

Temps avant

Temps après

Réduction du temps

Temps d'initialisation FileMonitoringInitializer lors du démarrage d'un projet vide

00: 00: 01.70

00: 00: 00.17

90%

Optimisations des performances d'exécution

Avec ces modifications, nous nous sommes concentrés sur la création du composant logiciel enfichable Frontfin Sitefinity , et donc, les visiteurs de votre site – plus heureux. Nous avons travaillé sur du code de très bas niveau qui est critique pour les performances du rendu des pages du site.

Optimisations des performances sur le visiteur d'expression

Cette optimisation est le principal contributeur à la réduction du temps de chargement des pages. Cette optimisation affecte le temps d'exécution de Sitefinity, le rendu des pages et constitue une amélioration globale des performances liée à la création de requêtes.

Pour effectuer une requête de base de données, Sitefinity crée un visiteur d'expression Sitefinity personnalisé pour créer une arborescence d'expression LINQ . . Pour des raisons historiques, la méthode Visite a été appelée deux fois pour chaque requête. Nous avons simplifié cela et avons commencé à invoquer la méthode Visite une seule fois.

Test

Temps avant

Temps après

Réduction du temps

Demande de page pour www.telerik.com [19659061] 00: 00: 02.81

00: 00: 01.39

51%

Optimisation des requêtes de données associées

Nous avons modifié l'implémentation de l'API GetRelatedItems et maintenant il interroge uniquement la base de données une fois que. Vous bénéficierez automatiquement de cette optimisation sans modifier votre code.

Requête du nombre de base de fournisseurs de données

Nous avons appliqué les modifications "Optimisation des requêtes de données associées" pour tous les fournisseurs de Sitefinity à un niveau bas. Nous avons également optimisé le code DataProviderBase et éliminé la requête de comptage qu'il a effectuée en interne.

Ces deux modifications ont un impact sur la plupart des opérations et augmentent la vitesse de presque toutes les opérations de l'utilisateur final.

Cache ObjectFactory pour la résolution des mêmes types

La résolution des types dans ObjectFactory est une opération très courante. L'API simple cache trop bien la complexité sous-jacente et les implications en termes de performances. En raison de l'utilisation omniprésente de ce modèle de code, nous avons décidé d'améliorer ses performances sans modifier l'API et introduit un cache pour les types résolus dans ObjectFactory .

Ce changement accélère presque toutes les opérations. Et tandis que la vitesse d'accélération pour un fonctionnement individuel n'est qu'un tout petit peu, le résultat composé est significatif et Sitefinity devient globalement plus rapide.

Test

Temps avant

Temps après

Réduction du temps

200 Config.Get opérations avec 5000 types enregistrés

00: 00: 00.35

00: 00: 00.01

97%

Requêtes de pages principales dans le menu principal

Cette optimisation affecte la première fois que vous ouvrez le backend Sitefinity et chargez le menu principal, où nous avons réduit le nombre de requêtes DB.

Test

Avant

Après

Amélioration

Nombre de requêtes DB au démarrage

Environ 400

Environ 50

Nombre de requêtes réduites de 80%

Temps pour Menu principal En charge

00: 00: 01.05

00: 00: 00.06

Temps réduit de 94%

Résolution optimisée du package MVC

Ce changement accélère les opérations comme l'affichage de pages contenant des widgets MVC.

Nous avons optimisé l'implémentation de la méthode PackageManager.PackageExists et il met désormais le package en cache dans le contexte pour la durée de vie de la demande.

Test

Temps avant

Temps après

Réduction du temps

Obtenir le package de page de ressources actuel lors de la demande de page MVC dans un projet vide

00: 00: 00.0126162

00:00: 00.0000021

99.98%

Navigation MVC optimisée

Vous serez particulièrement satisfait de ce changement si vous avez un widget Navigation MVC affichant plusieurs pages.

Nous avons optimisé le AddChildNodes méthode invoquée à partir du widget MVC Navigation . Auparavant, cette méthode devait parcourir l'intégralité de l'arborescence du plan du site, ce qui n'était pas obligatoire dans la plupart des cas. Nous avons considérablement accéléré ce processus. Vous bénéficierez automatiquement de cette modification sans modifier votre code.

Récapitulatif

Une poignée de touches stratégiques s'ajoutent à une amélioration significative des performances de Sitefinity 12.2, que les développeurs et les éditeurs de contenu apprécieront certainement. Mieux encore, la différence que cela fait pour vos utilisateurs finaux sera également largement remboursée. Après tout, les gens sont beaucoup plus susceptibles de s'engager avec des sites Web à chargement rapide et réactifs.

Et ce n'est pas seulement la vitesse et les performances. Sécurité et productivité, apparence générale – il y a des raisons de mettre à niveau petits et grands. Obtenez 12.2 et vous saurez ce que nous voulons dire. Ne manquez pas encore la meilleure expérience Sitefinity.

MISE À NIVEAU MAINTENANT

Alternativement, si vous préférez une visite guidée par un expert Sitefinity, n'hésitez pas à planifier une démo. Nous sommes impatients de répondre à toutes vos questions.

ANNEXE A DEMO




Source link