Lorsqu’un projet a trop de pages, IIS démarre et le site web est très lent lors de l’ouverture pour la première fois, car le projet n’est pas précompilé au moment de la sortie, mais est compilé dynamiquement lorsque l’utilisateur visite la page web. Si vous souhaitez améliorer les performances de votre site existant et effectuer une vérification des erreurs sur votre site, il est nécessaire de sélectionner « Précompiler lors de la publication » lors de la publication de votre projet.
Introduction
Pour les petits projets, publier selon les paramètres par défaut peut pratiquement répondre à l’opération normale, la première page s’ouvre en 56 secondes (selon la configuration du serveur), et la première ouverture des autres pages se termine en 12 secondes, et non la première ouverture instantanée.
Une fois que les fonctions du projet deviennent complexes et que le nombre de fichiers augmente, il faudra plus de 30 secondes pour ouvrir la première page lors de la première publication après publication, et environ 10 secondes pour la première ouverture des autres pages, pas pour la première ouverture instantanée.
Cela s’explique par le fait que le projet n’est pas précompilé au moment de la sortie, mais est compilé dynamiquement lorsque l’utilisateur accède à la page web, et une fois le pool d’applications recyclé ou les fichiers du projet modifiés, il sera recompilé et subira à nouveau une « première fois » lente, ce qui est intolérable.
Avantages de la précompilation
- Performance. Le code compilé est exécuté beaucoup plus rapidement que les langages de script tels qu’ECMAScript ou VBScript car il s’agit d’une représentation plus proche du code machine et ne nécessite pas d’analyse supplémentaire.
- Sécurité. Le code compilé est plus difficile à rétroconcevoir que le code source non compilé car il manque de la lisibilité et de l’abstraction que possèdent les langages de haut niveau. De plus, les outils de fuzzing améliorent la capacité du code compilé à résister au traitement de rétro-ingénierie.
- Stabilité. Vérifiez votre code pour détecter des erreurs de syntaxe, des problèmes de sécurité des types et d’autres soucis lors de la compilation. En détectant ces erreurs au moment de la compilation, de nombreuses erreurs peuvent être éliminées dans le code.
- Interopérabilité. Puisque le code MSIL supporte n’importe quel langage .NET, il est possible d’utiliser des assembleurs initialement écrits dans d’autres langages dans le code. Par exemple, si vous écrivez ASP.NET page web en C#, vous pouvez ajouter une référence à un fichier .dll écrit en Visual Basic.
ASP.NET Core précompilé
Précompilé
La précompilation est la méthode par défaut pour ASP .Net Core. Au moment de la publication, toutes les vues Razor dans le système sont précompilées par défaut. La DLL vue compilée porte un nom uniforme xxx.PrecompiledViews.dll ou xxx.Views.dll
Compilation dynamique
Il est facile de configurer l’ensemble du projet en compilation dynamique, il suffit d’ajouter un projet de configuration MvcRazorCompileOnPublish avec une valeur false
ASP.NET Précompilation du site web
Nous utilisons Visual Studio pour publier un site web de la manière suivante :
La signification de l’option « Permettre les mises à jour de ce site précompilé » Lorsque nous publions un projet web .Net, en général, tous les fichiers . CS, qui génère automatiquement une bibliothèque de liaison dynamique DLL, capable de très bien protéger le code source du site web, car le code côté serveur est généralement placé dans . Puisque les fichiers DLL dans le fichier CS sont tous générés, puis téléchargés sur le serveur, les autres ne peuvent pas facilement les ouvrir !
Cependant, d’autres fichiers, comme ashx, aspx et d’autres fichiers, ce qu’ils contiennent est ce que c’est, d’autres peuvent ouvrir ces fichiers pour les consulter, bien que d’autres ne puissent pas voir le code CS, mais peuvent toujours voir le code HTML ou certains contrôles serveur et attributs associés dans le fichier ASPX ; Un fichier comme ashx est équivalent à un fichier CS, et le code qu’il contient est facilement visible ;
Par conséquent, . Les fichiers CS sont sûrs, mais ASPX, ashx et d’autres fichiers ne le sont pas ; Alors, existe-t-il un moyen de rendre les fichiers web téléchargés sur le serveur en sécurité ? Il existe un moyen, c’est-à-dire que, lors de la publication, il ne faut pas cocher « Permettre les mises à jour de ce site précompilé » ;
Vérifier les mises à jour « Autoriser » de ce site précompilé
Si vous cochez « Permettre de mettre à jour ce site précompilé » lors de la publication du web, alors le résultat est le suivant : le fichier web entier, à l’exception de tous les fichiers CS compilés en fichiers DLL, d’autres fichiers, et l’original n’a aucun changement, ce qu’il y a à l’intérieur, ou quoi, tant que d’autres l’ouvrent via Notepad, le code, le code HTML, etc. à l’intérieur peuvent être vus d’un coup d’œil par d’autres.
De plus, lorsque les utilisateurs visitent une page pour la première fois, il faut les compiler pour détecter les bugs, et s’il n’y a pas d’erreurs, ils peuvent être accessibles normalement, ce qui rendra la vitesse relativement lente. Les visites après cela sont normales ;
Décochez « Permettre les mises à jour de ce site précompilé »
Si vous ne cochez pas « Autoriser la mise à jour de ce site précompilé » lors de la publication du web, alors le résultat est le suivant : 1. Tous les fichiers CS du site web sont compilés en fichiers DLL ; 2. En plus du fichier cs, d’autres fichiers, tels que ASPX, ASHX et d’autres fichiers, sont également compilés ensemble, et chaque fichier génère un fichier *.compiled correspondant dans le répertoire BIN ;
Ensuite, si vous consultez ASPX, ASHX et d’autres fichiers via le bloc-notes, vous ne verrez aucun code dedans, même le balisage HTML n’est pas visible, ouvrez un tel fichier, il n’y a qu’une seule ligne de texte, le contenu est « Ceci est un fichier de balisage généré par l’outil précompilé, il ne doit pas être supprimé ! », et la taille de ces fichiers est de 1 ko ;
Si vous essayez d’ouvrir une page web, vous constaterez que sauf pour la première page après le début du projet, qui prend toujours 1~2 secondes (pas d’EF), la première fois que chaque autre page s’ouvre instantanément (la première lenteur de l’EF dépasse le cadre de cet article). Ça me donne l’impression d’être en retard pour voir les précompilés !
Ici, je vous dis en secret que supprimer le répertoire Vues n’affectera pas l’ouverture normale de la page web~ Pourquoi ne laissez-vous pas la supprimer ? Nous n’osons pas demander, et nous n’osons pas la supprimer.
L’objectif a été atteint, et il y avait quelques conséquences à résoudre, comme le désordre dans le répertoire bac.
Sélectionnez « Ne pas fusionner ». Créez des assemblages séparés pour chaque page et contrôle », et le résultat est beaucoup plus de fichiers App_Web_*.dll dans la boîte.
Au moment de la sortie, la racine du projet génère un fichier PrecompiledApp.config. Le contenu est le suivant :
Le fichier PrecompiledApp.config sert à suivre le déploiement de l’application et si ASP.NET doit compiler des fichiers au moment de la demande. |
Publié le 22-08-2020 à 10:05:17
|
|
|
|
