Optimisation de votre application Core ASP.NET

Si vous n’utilisez pas ces six conseils pour accélérer votre application Core ASP.NET, votre application n’est pas en marche aussi rapidement que possible. Et l’implémentation de l’un de ces éléments accélérera suffisamment votre application pour que vos utilisateurs le remarquent.

Les deux choses les plus lentes que vous puissiez faire dans le traitement des données sont:

• Passer un appel à un autre ordinateur, surtout si vous utilisez HTTP, le protocole le plus lent du monde
• Effectuer des E / S de disque

Ce sont des problèmes majeurs dans une application de base ASP.NET axée sur les entreprises qui est a) basée sur la réception d’appels HTTP sur Internet, et b) le déclenchement des E / S de disque en effectuant des demandes de base de données.

Et puis cela empire: en tant que développeur de base ASP.NET, vous n’avez aucun contrôle sur l’une ou l’autre latence du réseau et très peu de contrôle sur les temps de réponse de la base de données. Ce qui signifie que, dans une application Core ASP.NET, il y a deux leviers que vous pouvez tirer pour obtenir un «Oh, c’était plus rapide!» Réponse de vos utilisateurs:

• Réponses plus rapides du serveur Web lorsque le navigateur demande une nouvelle page
• Des temps de chargement plus rapides lorsque cette page arrive au navigateur

Et vous voulez tirer ces deux leviers car il y a très peu que les utilisateurs aiment mieux qu’une interface utilisateur rapide et réactive. Voici donc six conseils (et un bonus) pour livrer une interface utilisateur plus rapide à vos utilisateurs.

Astuce 1: ne configurez pas plus que ce dont vous avez besoin

Tout d’abord: dans votre fichier Program.cs, vous devez profiter des options de configuration d’Asp.net Core pour refuser votre application et ne charger que les composants dont votre application a besoin. Cela vous permet de commencer par une application légère et agile.

Astuce 2: Passez à la base de données

Si vous pouvez éliminer les voyages vers le serveur de base de données, vous pouvez couper l’une de ces «deux choses les plus lentes dans le traitement des données». Vous pouvez éliminer les voyages vers votre serveur de base de données en utilisant l’objet MemoryCache de .NET à Cache, en mémoire, les 20% des données qui gère 80% des demandes de votre application. L’astuce ici est que les données mises en cache font pas Reflétez les modifications apportées à la base de données après la récupération des données dans le cache, vous devez donc faire face à vos données en cache.

Le moyen le plus simple d’implémenter la mise en cache est de mettre tous vos données d’accès aux données dans des méthodes dans une classe de référentiel, puis de demander à votre application d’appeler ces méthodes de référentiel lorsqu’elle a besoin de données. Dans ces méthodes de référentiel, lorsque vous récupérez toutes les données, ajoutez-la à MemoryCache afin que la prochaine demande n’a pas doivent aller sur le serveur de base de données.

Vous avez trois choix pour gérer les données périmées dans le cache:

1. Choisissez des données pour votre cache qui ne changent pas souvent ou changent en dehors des heures de bureau.
2. Cachez les données avec un délai d’expiration spécifié, après quoi les données seront purgées du cache. La purge des données d’ici la fin du jour ouvrable signifie que, demain, la première demande de l’application ramassera toutes les données mises à jour du jour au lendemain.
3. Ajoutez un paramètre booléen en option à votre méthode qui déclenche la nettoyage du cache. Lorsque le cache est vide, votre code fait ce voyage dans la base de données pour obtenir les dernières données (et rafraîchir le cache pour les demandes ultérieures). Les applications peuvent utiliser ce paramètre lorsqu’ils doivent absolument avoir les dernières données.

Voici un exemple typique avec un contrôleur appelant le référentiel:

public class HomeController
{
  CustomerRepository custRepo = null;
 
 public Home(IMemoryCache cache)
  {   
     custRepo = new CustomerRepository(cache);
  }
 
  public IActionResult Index(string cId, bool force = false)
  {
     Customer cust = custRepo.GetCustomerById(cid, force)
     return View(cust);
  }
}

public class CustomerRepository
{
  private IMemoryCache cache;
  
  public CustomerRepository(IMemoryCache cache)
  {
       this.cache = cache;
  }
  public async Customer Index(string cId, bool force = false)
  {
     if (force)
     {
        cache.Remove(cId);
     }
    Customer cust = await cache.GetOrCreateAsync<Customer>(
          cId,
          async e => {
                                    e.cacheEntry.AbsoluteExpirationRelativeToNow = 
                                                                                       TimeSpan.FromMinutes(30);
                                   return await GetCustomerAsync(cId);
                                }
        );
  return cust;
}
…

Si vous travaillez dans une ferme de serveurs, vous ne souhaitez pas mettre en cache des données sur des serveurs individuels (ce qui peut entraîner une incohérence si un serveur de la ferme a mis en cache une version de l’élément qui a des valeurs différentes de la version mise à jour de cet élément sur un autre serveur dans la ferme).

Au lieu de cela, dans une ferme de serveurs, profitez de la prise en charge de base ASP.NET pour une variété de Solutions de mise en cache distribuéesy compris Redis, Ncache et SQL Server (qui utilise des tables OLTP en mémoire pour accélérer l’accès aux données).

Astuce 3: N’envoyez pas plus que ce dont vous avez besoin au client

Soyez judicieux quant à la transmission des données au client: plus vous envoyez de données au client lors d’une demande de page pour la première fois, plus l’affichage initial de cette page sera lent. Plus précisément, si vous avez récupéré une grande liste de données que vous serez affichées dans une grille, ne le faites pas Affichez toutes les lignes à la fois. En fait, ne téléchargez aucune donnée avant que la page ne s’affiche, que l’utilisateur soit occupé à lire la page et ne vous dérange pas (autant) que les données sont toujours en route.

Lorsque vous fournissez les données, téléchargez juste assez pour que votre utilisateur soit satisfait de l’affichage initial de votre grille. Il y a deux scénarios ici:

• Si vous implémentez la pagination, téléchargez juste assez de données pour la première page.
• Si vous utilisez une grille avec «Infinite Scroll», téléchargez juste assez de données pour remplir la page Web (et un peu plus).

Progress Telerik UI pour ASP.NET Core Grid prend en charge ceci tout comme le Grille de blazor.

Astuce 4: Téléchargez ce dont vous avez besoin de plus près du navigateur

Si les fichiers CSS et JavaScript que votre page utilise sont une technologie standard de l’industrie (par exemple, bootstrap pour CSS, React ou Angular), obtenez ces fichiers à partir de l’un des sites de réseau de livraison de contenu (CDN) désignés. Alors qu’un CDN est accessible via une seule URL, les nœuds soutenant que l’URL sont dispersés à travers le monde. À moins que vos clients ne soient concentrés près de votre centre de données, il est à peu près certain que vos utilisateurs sont plus proches d’un nœud CDN que de votre serveur de données.

Lorsque vous récupérez à partir d’un CDN, le pire des cas est que le nœud CDN local de l’utilisateur n’a pas de copie du fichier demandé (peu probable, mais possible). Si c’est le cas, la demande de l’utilisateur remplira le nœud CDN afin que toute demande ultérieure de cet utilisateur (ou de tout autre utilisateur local au CDN) rapporte le fichier à partir de ce nœud. De plus, si le navigateur de l’utilisateur a déjà chargé ce fichier standard de l’industrie à partir du CDN lors d’une visite à un autre site, le navigateur de votre utilisateur continuera à utiliser cette version téléchargée plutôt que de récupérer à nouveau le fichier.

Vous pouvez également envisager de déplacer vos propres fichiers personnalisés vers un CDN (par exemple, le Réseau de livraison de contenu Azure). Après tout, votre utilisateur à Singapour a-t-il vraiment besoin d’atteindre le monde entier vers votre serveur dans le New Jersey juste pour télécharger le logo de votre entreprise?

Astuce 5: Télécharger des fichiers plus petits et moins

Même après avoir déménagé à un CDN pour vos fichiers standard, votre application peut toujours inclure beaucoup de vos propres fichiers JavaScript et CSS.

Vous devriez minimiser ces fichiers pour éliminer ce qui n’est pas requis sur le navigateur (espaces, retours de chariot, indentation, noms de variables significatifs – tout ce qui rend votre contenu de fichier lisible). Les téléchargements de vitesses de vos fichiers sur les téléchargements et obtient votre page plus rapidement.

Et, comme les navigateurs modernes prennent en charge le protocole GZIP, vous devriez également zipper vos fichiers CSS et JavaScript en bundles plus petits et compressés qui téléchargeront plus rapidement, accélérant votre affichage initial de page.

Il y a un autre avantage, en plus des fichiers plus petits, ici: dans HTTP 1.1, votre navigateur est limité à sept demandes simultanées. A regrouper vos fichiers CSS signifie seulement deux demandes (une pour votre bundle CSS et une pour votre bundle JavaScript) obtient votre navigateur tous vos fichiers CSS et JavaScript.

Le navigateur déballera ces faisceaux au fur et à mesure qu’ils sont reçus et cela mangera une partie du temps que vous avez enregistré pour télécharger moins de fichiers plus petits, mais vous serez probablement encore en tête. Bien sûr, vous devrez mettre à jour votre <link> et <script> Éléments pour pointer vers vos fichiers zippés afin que le navigateur les utilise.

De toute évidence, quels que soient les avantages du regroupement et de la minimisation, il y a un travail supplémentaire ici que vous préférez ne pas faire à la main. Heureusement, ASP.Net Core est compatible avec Weboptimizerqui minimera et regroupera vos fichiers CSS et JavaScript à l’exécution.

Astuce 6: appelez le serveur moins

Lorsque vous renvoyez une page de votre application Core ASP.NET, profitez du ResponseCache L’attribut, en particulier pour les pages fréquemment demandées – qui évite que le navigateur fasse un voyage sur votre serveur Web.

Le ResponseCache L’attribut, appliqué à une méthode d’action, ordonne aux clients et aux procurations de conserver les pages renvoyées par votre application. Le navigateur satisfera ensuite les demandes ultérieures pour ces pages de ces résultats enregistrés plus proches plutôt que d’envoyer une autre demande de votre serveur plus éloigné. Vous donnez non seulement à vos utilisateurs une réponse plus rapide, mais vous réduisez la demande sur votre serveur Web afin que vous puissiez gérer plus de demandes, plus rapidement.

Vous voudrez utiliser les réponses VaryByQueryKeys Méthode de sorte que l’utilisateur obtient une version de la page qu’il souhaite. Cet exemple indique aux clients et aux proxys de cache (pendant 10 minutes) chaque version de la page générée par une valeur différente dans la question de la question country paramètre:

[ResponseCache(Duration = 600, VaryByQueryKeys = new string[] { "country" } )]
public IActionResult GetPriceList(string country)
{

Conseil bonus: utilisez l’async

Cette astuce n’appartient pas vraiment à cet article car elle ne fait pas plus rapidement l’exécution de votre application ASP.NET, il aide simplement à faire en sorte que votre application s’exécute, même si le nombre de demandes s’accumule.

Quelque chose d’arrière-plan: chaque fois qu’une demande pour votre site frappe votre serveur Web, la demande se voit attribuer un thread sur lequel s’exécuter. Il y a toujours une limite au nombre de threads dans le pool Web de votre site et, si vous obtenez suffisamment de demandes, ce pool sera épuisé. Lorsqu’il n’y a plus de threads dans la piscine, la prochaine demande de votre site devra attendre qu’un fil soit disponible (c’est-à-dire quand un autre, l’exécution du fil se termine et est renvoyé à la piscine).

Si une demande qui attend sur un thread attend «trop long» (et que ce temps est réglable – parlez à votre administrateur de serveur), la demande sera refusée, probablement avec un message «Service non disponible» 503.

Le problème est que, dans une application commerciale, la plupart des demandes dites de «fonctionnement» qui ont pris un fil dans le pool ne fonctionnent probablement pas. Dans une application commerciale, la plupart des demandes finissent par appeler un serveur de base de données ou un service Web, qui sont tous deux des appels exécutés sur un CPU complètement différent de votre serveur Web. En conséquence, dans une application commerciale, le thread sur le serveur Web affecté à la demande passe une grande partie de son temps au ralenti, en attendant la demande de la base de données ou du service Web à retourner.

L’utilisation d’Async lors des appels vers un ordinateur distant rejette efficacement le thread de la demande de ralenti dans le pool de threads du serveur Web où le thread peut être utilisé par une autre demande. Et, oui, lorsque l’appel à la base de données ou au service Web revient au serveur Web, le serveur Web devra trouver un thread pour continuer à exécuter la demande d’origine. Mais, avec des fils retournés régulièrement dans la piscine parce que vous utilisez asynchronisé avec diligence, ce ne sera pas un problème.

Votre tour

Vos utilisateurs veulent simplement continuer leur travail, et autre chose qu’une interface utilisateur rapide et réactive se met en travers. L’accélération de votre application rendra non seulement votre utilisateur plus heureux, mais augmentera les chances que les gens utilisent réellement votre application.

Mais qu’est-ce que j’ai manqué? Quel est votre meilleur conseil pour accélérer votre application Core ASP.NET? Ou où ai-je ignoré les problèmes avec ces conseils? Publiez ci-dessous et aidez le prochain lecteur.