Performance
For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /fr/docs/04-performance/index.md.
Les journaux de débogage DNS sur un contrôleur de domaine très actif sont volumineux. Convert-DNSDebugLogFile est conçu pour ce cas : il a été testé avec des journaux de 100 Mo et plus, et les traite en quelques minutes sur du matériel serveur ordinaire.
Pourquoi c’est rapide
Vous n’avez pas besoin de connaître tout cela pour utiliser le module, mais cela explique le comportement que vous observerez.
| Technique | Effet que vous remarquez |
|---|---|
StreamReader / StreamWriter avec des tampons de 64 Ko | Le fichier est lu et écrit par morceaux au lieu d’un gros Get-Content |
| Streaming, passage unique | L’utilisation mémoire reste à peu près constante, quelle que soit la taille du journal |
Opérations sur chaînes (.Substring(), .IndexOf()) au lieu d’expressions régulières | Beaucoup moins de CPU par ligne, et il y a des millions de lignes |
CSV écrit à la main au lieu de Export-Csv | Pas de surcharge de pipeline d’objets par enregistrement |
| Agrégation basée sur des tables de hachage pour les statistiques | Les regroupements coûtent presque rien en plus pendant le même passage |
La conséquence importante : le journal complet n’est jamais chargé en mémoire. Un journal de 500 Mo ne nécessite pas 500 Mo de RAM. C’est la différence entre le module et l’approche « lire le fichier, le découper, construire des objets » que la plupart des scripts maison utilisent — cette approche fonctionne bien sur un échantillon de 5 Mo mais plante sur un vrai DC.
Tirer le meilleur parti d’une exécution
Convertir des morceaux tournés, pas un fichier géant
Configurez le serveur DNS pour faire tourner le journal à une taille gérable — 50 à 200 Mo est une bonne plage. Plusieurs fichiers moyens se convertissent en un temps prévisible et permettent à une tâche planifiée de finir dans sa fenêtre. Un fichier qui ne cesse de grossir finit par ne plus y arriver.
La rotation vous donne aussi des fichiers fermés avec lesquels travailler, ce que vous voulez de toute façon :
Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -Skip 1 |
Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME
Sauter l’analyse détaillée quand ce n’est pas nécessaire
Si le serveur DNS écrit les détails complets des paquets, transformer ces blocs en JSON est la partie la plus coûteuse de la conversion.
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing
Attendez-vous à des exécutions 30 à 50 % plus rapides sur les journaux contenant beaucoup de blocs détaillés, plus un CSV beaucoup plus petit. Vous obtenez toujours les données au niveau des requêtes et la ligne d’en-tête détaillée TCP/UDP dans Information. Voir Paramètres et Options.
Filtrer tôt
-ContextFilter Packet élimine les notes et événements du serveur avant qu’ils ne soient écrits. Moins de sortie signifie moins d’E/S, des fichiers plus petits, et moins de travail en aval.
Demander uniquement ce dont vous avez besoin
-OutputType Statistic évite complètement d’écrire le CSV ligne par ligne. Si votre tableau de bord affiche seulement des comptes journaliers, c’est de loin l’option la moins coûteuse.
Convertir localement, déplacer les résultats
Le module lit les chemins SMB/UNC, mais transférer un journal brut de 200 Mo sur le réseau pour le parser centralement est la méthode lente. Convertissez sur le serveur DNS, puis déplacez le CSV (compressé) — c’est généralement un dixième des octets. C’est le principe derrière l’exemple de collecte pilotée par GPO.
Compresser pour le transfert et l’archivage
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput
Un CSV de cette forme se réduit typiquement de 90 % ou plus. La compression coûte un peu de CPU à la fin de l’exécution et économise beaucoup d’espace disque et de bande passante ensuite.
Quand une exécution est plus lente que prévu
Vérifiez ces points dans l’ordre :
- Disque, pas CPU. La conversion est gourmande en E/S. Un journal sur un volume très occupé, ou lu via un lien lent, domine le temps d’exécution.
- Blocs détaillés. Si le journal contient les détails complets des paquets et que vous n’avez pas utilisé
-NoDetailsParsing, c’est là que le temps se passe. - Taille du fichier. Un seul journal de plusieurs gigaoctets prendra du temps quoi qu’il arrive. Réglez cela avec la rotation, pas avec des paramètres.
- Antivirus. L’analyse en temps réel du journal source et du CSV généré peut doubler le coût effectif des E/S. Une exclusion pour le répertoire des journaux est une mesure courante et raisonnable.
- Pression mémoire. Le module utilise le streaming, donc ce ne devrait pas être la cause — mais un serveur déjà en swap ralentira tout.
D’autres symptômes et solutions sont rassemblés dans Dépannage.