Est-ce une bonne pratique d’utiliser la compression NTFS sur les dossiers et fichiers de journaux IIS ?
J’ai pu passer de 20 Go à 7 Go en faisant cela. Les journaux IIS sont journaliers et ont une taille moyenne de 20 Mo, mais certains jours extrêmes atteignent 200 Mo.
Je me demande si IIS doit ouvrir le fichier entier en mémoire, forçant NTFS à décompresser 20 Mo (ou 200 Mo dans les cas extrêmes) à chaque fois ? Ou y a-t-il une astuce qui permet à IIS d’ajouter du contenu ? Quel est l’impact sur le système ? Cela pourrait-il devenir un problème si notre trafic augmente ?
Devrais-je les découper par heure au lieu de par jour ?
Y a-t-il un document officiel de Microsoft à ce sujet ? Je n’ai pas pu en trouver un.
Je compresse mes journaux IIS sur beaucoup de serveurs IIS, bien que principalement des serveurs hébergeant Outlook Web Access/App ou des sites web à faible volume. Je n’ai aucun problème à le faire, et j’apprécie bien les économies d’espace disque.
En général, vous échangez du CPU contre du stockage en prenant cette décision. Si vous êtes déjà limité par le CPU, ce n’est probablement pas un bon compromis. Pour mes serveurs OWA, qui peuvent générer des gigaoctets de journaux par jour (merci les appareils ActiveSync), je pense que le compromis en vaut la peine.
Le pilote du système de fichiers NTFS gère la compression, donc cela ne change pas la façon dont IIS écrit dans les fichiers.
Modification :
Vous échangez aussi potentiellement de la bande passante d’E/S et des IOPS. Si vous avez un volume suffisamment élevé pour que vos écritures de journaux représentent une consommation significative de ressources d’E/S, vous pourriez constater une diminution de la consommation d’E/S en activant la compression.
Le seul moyen de savoir comment cela vous impacte est de le mesurer vous-même. Prenez une référence avec la compression désactivée puis activée et comparez-les. Il n’y a pas de baguette magique pour savoir comment cela vous impactera – il y a simplement trop de facteurs non déterministes en jeu.