IIS7: différences entre la compression statique et dynamique du contenu
IIS supporte deux types de compression: statique compression de contenu etdynamique compression de contenu. Selon applicationHost.config, ils sont gérés par différents modules: DynamicCompressionModule (compdyn.dll) et Static Compressionmodule (compstat.dll), et ils sont configurés pour compresser les différents types de demandes. De plus, je suppose que la compression dynamique ne cache pas les requêtes compressées par opposition aux la compression statique (par défaut, les fichiers compressés sont enregistrés à %SystemDrive%inetpubtempIIS Temporary Compressed Files).
cependant, à part ces différences évidentes, je soupçonne qu'il y a autre chose. je pense qu'ils se raccordent au pipeline de L'IIS d'une façon légèrement différente. Quelqu'un ont un intérieur en un peu plus de détails?
La j'ai trouvé que je jouais avec un module personnalisé pour modifier les fichiers CSS à la volée. Lorsque la compression statique a été activée (et réglé pour gérer le jeu de fichiers par défaut, c.-à-d. aussi text/css), sur la demande mise en cache mon module personnalisé a été servi le contenu déjà gzippé. Quand j'ai déplacé text/css dans la liste des requêtes dynamiquement compressées, tout a commencé à fonctionner. Mais je voudrais avoir une plus solide, la preuve que c'est vraiment la bonne façon de le faire. Y a t'il d'autres conséquences connues / problèmes?
mise à Jour: je crois que j'ai une théorie sur pourquoi il se passe. Il ne peut pas être 100% correct, mais au moins cela peut expliquer le comportement observé. Je pense que le module de compression statique s'enregistre aux événements suivants (entre autres):
RQ_MAP_REQUEST_HANDLER
RQ_EXECUTE_REQUEST_HANDLER
puis quand une requête pour un fichier statique est servie, le module de compression statique dans OnMapRequestHandler vérifie si le fichier a été compressé à l'avant, et si le fichier n'a pas été modifié. Si c'est le cas, il ré-associera la requête à lui-même (retournant la redirection appropriée en utilisant IMapHandlerProvider). Quand il sert plus tard réellement la réponse dans OnExecuteRequestHandler, il envoie le fichier compressé. Si, d'un autre côté, le fichier n'a pas été compressé avant ou s'il a changé, il ne fait pas la redirection de mappage et laisse le module de contenu statique servir la requête et puis plus tard dans Onpostexecuterequetler compresse le contenu (et met à jour son cache). Comme mentionné ci-dessus, je ne dis pas que c'est exactement ce qui se passe (Je ne connais pas le code source), il se peut que ce ne soit qu'une approximation. De plus, le module de compression dynamique ne fait probablement rien de tout cela. Il comprime simplement les réponses sortantes parfois après RQ_EXECUTE_REQUEST_HANDLER.
2 réponses
Ta question n'est pas très clair, donc je vais répondre à une question et j'espère que c'est votre question.
le but de la compression statique est de compresser des fichiers qui seraient autrement servis directement à partir du disque dur (css/images/javascript) et en tant que tel, il comprime chaque fichier une fois et sauvegarde le fichier compressé sur le disque. Cela permet de servir très rapidement et à bon marché du contenu compressé pour des fichiers statiques qui changent rarement. C'est une recommandation assez sûre d'en dire plus site web devrait avoir la compression statique activée.
le but de la compression dynamique est de comprimer les réponses dynamiques des modules de L'ISS (asp, asp.net, php, etc.). Comme cette réponse peut être différente pour chaque requête, la sortie compressée ne peut pas être mise en cache. Cette caractéristique est nouvelle à partir de IIS6, bien que l'effet ait été réalisable dans certains environnements, par exemple en mettant en œuvre un ASP.Net. Comme chaque requête doit être compressée à la volée, ceci est beaucoup plus intensif en CPU que la compression statique. Donc, si un serveur est lié au CPU, ce n'est peut-être pas une bonne option. La plupart des sites sont reliés à un réseau et/ou à une base de données, ce qui en fait souvent une bonne idée.
ainsi la dynamique et la statique se réfèrent au contenu et à l'effet quelles stratégies peuvent être utilisées.
Quelques Références
expérimentant avec la fonction de compression IIS, il m'est apparu que le module dynamique et le module statique ne sont pas aussi liés au contenu dynamique ou statique (particulièrement pour le module dynamique).
activez la compression pour text/html (ou text/*) type mime Sur module dynamique, et non sur module statique. Accéder à une .fichier html. Vérifie la réponse http dans le navigateur: elle est compressée. (Testé sur IIS 7.5 sur le serveur 2008R2.)
il semble que le module de compression dynamique n'est pas limité à le contenu dynamique. Il fait du contenu statique comprimé à condition qu'il corresponde à sa liste de types mime et qu'il ne soit pas déjà comprimé. Donc je considère qu'il doit être compris comme un "module de compression" dynamique, dans le sens où il est déclenché sur chaque réponse (basé sur ses critères de type mime, et sur accept-encoding en-tête de demande).
alors que le module de compression statique est déclenché un peu comme un processus de travail en arrière-plan sur les fichiers, et commence à servir la sortie compressée seulement une fois qu'il les a dans son cache. Puisque le module de compression statique exécute farer dans la pile de modules, il gère la réponse avant le module de compression dynamique, et donc ont priorité sur dynamique un si elle a comprimé la sortie pour servir.
donc pour votre cas d'utilisation spécifique, vous devriez désactiver le module de compression statique sur text/css type mime (attention à supprimer text\* trop si présent) afin d'éviter les problèmes de mise en cache vaincre votre css personnalisé correctifs module.
Vous pouvez en outre activez la compression de text/css dans le module de compression dynamique pour remplacer le module de compression statique sur ce cas. Mais bien sûr, il ne va pas alors tirer parti de la capacité de mise en cache du module de compression statique.
malheureusement, je n'ai pas trouvé de documentation pour étayer les déclarations ci-dessus.
une autre option pourrait être d'essayer de modifier l'ordre d'exécution du module IIS. Vous devriez les supprimer tous dans votre configuration de site, puis les ajouter à nouveau, en insérant votre module personnalisé peut-être avant la compression statique. Mais ça pourrait être un chemin délicat.