Comment activer la compression HTTP gzip sur le contenu dynamique Windows Azure

Question

J'ai essayé en vain d'activer gzip compression HTTP sur mon Windows Azure hébergé WCF service Restful qui renvoie du JSON seulement à partir de GET et POST demandes.

J'ai essayé beaucoup de choses que j'aurais un moment difficile avec une liste de tous, et je me rends compte maintenant que je travaille avec des informations contradictoires (concernant l'ancienne version d'azur etc) donc pense qu'il vaut mieux commencer avec une ardoise propre!

Je travaille avec Visual Studio 2008, à l'aide de la février 2010 tools pour Visual Studio.

Ainsi, selon le lien suivant, la compression HTTP est maintenant activé ..

http://msdn.microsoft.com/en-us/library/ff436045.aspx

... et j'ai utilisé les conseils à la page suivante (l'URL de la compression des conseils seulement), mais je n'ai pas de compression.

http://blog.smarx.com/posts/iis-compression-in-windows-azure

<urlCompression doStaticCompression="true" doDynamicCompression="true" dynamicCompressionBeforeCache="true" />

Cela n'aide pas que je ne sais pas quelle est la différence entre urlCompression et httpCompression. J'ai essayé de trouver mais en vain!

Le fait que les outils pour Visual Studio a été publié avant la version d'Azur qui prend en charge la compression d'être un problème? J'ai lu quelque part qu'avec les derniers outils, vous pouvez choisir la version de Azure système d'exploitation que vous souhaitez utiliser lorsque vous publiez ... mais je ne sais pas si c'est vrai, et si elle l'est, je ne trouve pas où choisir. Pourrais-je être l'aide d'un pré-http version activée?

J'ai aussi essayé de blowery http compression module, mais pas de résultats.

Ce que quelqu'un a une date de conseils sur la façon de réaliser cet objectif? à savoir, les conseils qui se rapporte à la version actuelle de l'Azur de l'OS.

Cheers!

Steven

Mise à jour: j'ai édité le code ci-dessus pour résoudre un type dans le web.config extrait.

Mise à jour 2: Tester les réponses à l'aide du whatsmyip URL affichée dans la réponse ci-dessous montre que mes réponses JSON à partir de mon service.svc sont retournés sans aucune compression, mais les pages HTML statiques SONT retournés avec la compression gzip. Des conseils sur la façon d'obtenir les réponses JSON pour compresser seront reçues avec reconnaissance!

Mise à jour 3: Essayé une réponse JSON de plus de 256 KO pour voir si le problème était dû à la réponse JSON étant plus petite que ce que mentionné dans les commentaires ci-dessous. Malheureusement, la réponse isstill de l'onu-compressé.

Answer 1

Eh bien il a fallu un très long moment ... mais j'ai enfin résolu ce problème, et j'ai envie de publier la réponse de quelqu'un d'autre qui est en difficulté. La solution est très simple et j'ai vérifié qu'il n'certainement le travail!!

Modifier votre ServiceDefinition.csdef fichier pour contenir ce dans le WebRole tag:

    <Startup>
      <Task commandLine="EnableCompression.cmd" executionContext="elevated" taskType="simple"></Task>
    </Startup>

Dans votre web-rôle, créez un fichier texte et l'enregistrer en tant que "EnableCompression.cmd"

EnableCompression.cmd doit contenir ceci:

%windir%\system32\inetsrv\appcmd set config /section:urlCompression /doDynamicCompression:True /commit:apphost
%windir%\system32\inetsrv\appcmd set config  -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost

.. et c'est tout! Fait! Cette mesure de la compression dynamique pour le json renvoyé par la web-rôle, qui, je pense, j'ai lu quelque part a plutôt étrange de type mime, alors assurez-vous de copier le code exactement.

Answer 2

Eh bien au moins je ne suis pas seul sur ce coup - et c'est encore un stupide PITA près d'un an plus tard.

Le problème, c'est un MIME d'incompatibilité de type. WCF renvoie la réponse JSON avec Content-Type: application/json; charset=UTF-8. La valeur par défaut pour la configuration d'IIS, environ à mi-chemin en bas de la page, ne pas l'inclure en tant qu'compressible type MIME.

Maintenant, il pourrait être tentant d'ajouter un <httpCompression> section de votre site web.config, et ajouter de l'application/json. Mais c'est juste une mauvaise façon de perdre une bonne heure ou deux, vous ne pouvez changer l' <httpCompression> élément à la applicationHost.config.

Il y a donc deux solutions possibles. Tout d'abord, vous pouvez changer votre WCF réponse à l'utilisation d'un type MIME qui est compressible dans la configuration par défaut. text/json travaillera donc en ajoutant ceci à votre service méthode(s) vous donnera la compression dynamique: WebOperationContext.Current.OutgoingResponse.ContentType = "text/json";

Alternativement, vous pouvez modifier l'applicationHost.fichier de configuration à l'aide de appcmd et une tâche de démarrage. C'est l'objet de discussions (entre autres choses) sur ce fil. Notez que si vous ajoutez que le démarrage de la tâche et de le lancer dans le dev de tissu, elle travaillera à la fois. La deuxième fois, ce sera un échec parce que vous avez déjà ajouté l'élément de configuration. J'ai fini par la création d'un deuxième projet de nuage avec un csdef fichier, de sorte que mon devfabric ne serait pas exécuter ce script de démarrage. Il y a probablement d'autres solutions.

Mise à jour

Ma suggestion pour des projets distincts dans le paragraphe précédent n'est pas vraiment une bonne idée. Non idempotent tâches de démarrage sont une très mauvaise idée, parce qu'un jour, le tissu Azure va décider de redémarrer votre rôle pour vous, la tâche de démarrage échoue, et il va aller dans un recyclage en boucle. Le plus probable dans le milieu de la nuit. Au lieu de cela, faire vos tâches de démarrage idempotent, évoqué sur ce fil.

Answer 3

Pour faire face aux problèmes rencontrés par la structure de développement local après le premier déploiement, j'ai ajouté les commandes appropriées au fichier CMD pour réinitialiser la configuration. De plus, je règle le niveau de compression ici spécifiquement, car il semble que la valeur par défaut soit zéro dans certains cas (tous?).

 REM Remove old settings - keeps local deploys working (since you get errors otherwise)
%windir%\system32\inetsrv\appcmd reset config -section:urlCompression
%windir%\system32\inetsrv\appcmd reset config -section:system.webServer/httpCompression 

REM urlCompression - is this needed?
%windir%\system32\inetsrv\appcmd set config -section:urlCompression /doDynamicCompression:True /commit:apphost
REM Enable json mime type
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost

REM IIS Defaults
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='text/*',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='message/*',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/x-javascript',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='*/*',enabled='False']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='text/*',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='message/*',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='application/javascript',enabled='True']" /commit:apphost
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='*/*',enabled='False']" /commit:apphost

REM Set dynamic compression level to appropriate level.  Note gzip will already be present because of reset above, but compression level will be zero after reset.
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+"[name='deflate',doStaticCompression='True',doDynamicCompression='True',dynamicCompressionLevel='7',dll='%%Windir%%\system32\inetsrv\gzip.dll']" /commit:apphost
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression -[name='gzip'].dynamicCompressionLevel:7 /commit:apphost
 

Answer 4

Cet article de MS explique comment créer un script pour JSON http://msdn.microsoft.com/en-us/library/windowsazure/hh974418.aspx .

Il traite de nombreux problèmes mentionnés, par exemple être capable de gérer le recyclage Azure, etc.

Answer 5

Oui, vous pouvez choisir l'OS que vous voulez, mais par défaut, vous obtiendrez la dernière.

La Compression est délicate. Il y a beaucoup de choses qui peuvent mal se passer. Êtes-vous par hasard en faisant ce test derrière un serveur proxy? Je crois IIS par défaut n'est pas d'envoyer du contenu compressé à la procuration. J'ai trouvé un outil pratique pour tester si la compression est de travailler quand je jouais avec ceci: http://www.whatsmyip.org/http_compression/.

Il semble que vous avez doDynamicCompression="false"... est-ce juste une faute de frappe? Vous voulez être sur si vous allez obtenir la compression sur JSON vous de retour à partir d'un service web.