Performance
For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /docs/04-performance/index.md.
DNS debug logs on a busy domain controller are big. Convert-DNSDebugLogFile is built for that case: it has been tested with logs of 100 MB and beyond, and it processes them in minutes on ordinary server hardware.
Why it is fast
You do not need to know any of this to use the module, but it explains the behaviour you will observe.
| Technique | Effect you notice |
|---|---|
StreamReader / StreamWriter with 64 KB buffers | The file is read and written in chunks instead of one big Get-Content |
| Streaming, single pass | Memory usage stays roughly flat no matter how large the log is |
String operations (.Substring(), .IndexOf()) instead of regular expressions | Considerably less CPU per line, and there are millions of lines |
CSV written by hand instead of Export-Csv | No object pipeline overhead per record |
| Hashtable-based aggregation for statistics | Rollups cost almost nothing extra during the same pass |
The important consequence: the whole log is never held in memory. A 500 MB log does not need 500 MB of RAM. This is the difference between the module and the “read the file, split it, build objects” approach most home-grown scripts take — that approach works fine on a 5 MB sample and falls over on a real DC.
Getting the most out of a run
Convert rotated chunks, not one giant file
Configure DNS Server to roll the log over at a manageable size — 50 to 200 MB is a good range. Several medium files convert in predictable time and let a scheduled job finish inside its window. One ever-growing file eventually does not.
Rollover also gives you closed files to work with, which is what you want anyway:
Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -Skip 1 |
Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME
Skip detail parsing when you do not need it
If the DNS server writes full packet details, turning those blocks into JSON is the single most expensive part of the conversion.
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing
Expect 30–50 % faster runs on logs that contain many detail blocks, plus a much smaller CSV. You still get the query-level data and the TCP/UDP detail header line in Information. See Parameters and Options.
Filter early
-ContextFilter Packet drops server notes and events before they are written. Less output means less I/O, smaller files, and less work downstream.
Ask only for what you need
-OutputType Statistic skips writing the row-level CSV entirely. If your dashboard only shows daily counts, this is by far the cheapest option.
Convert locally, move the results
The module reads SMB/UNC paths, but pulling a 200 MB raw log across the network to parse it centrally is the slow way round. Convert on the DNS server, then move the (compressed) CSV — that is usually a tenth of the bytes. This is the design behind the GPO-driven collection example.
Compress for transfer and archive
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput
CSV of this shape typically shrinks by 90 % or more. Compression costs a little CPU at the end of the run and saves a lot of disk and network afterwards.
When a run is slower than expected
Check these in order:
- Disk, not CPU. Conversion is I/O-heavy. A log sitting on a busy volume, or read over a slow link, dominates the runtime.
- Detail blocks. If the log contains full packet details and you did not use
-NoDetailsParsing, that is where the time goes. - File size. A single multi-gigabyte log will take a while regardless. Fix this with rollover, not with parameters.
- Antivirus. Real-time scanning of both the source log and the generated CSV can double the effective I/O cost. An exclusion for the log directory is a common and reasonable measure.
- Memory pressure. The module streams, so it should not be the cause — but a server already swapping will make everything slow.
More symptoms and fixes are collected in Troubleshooting.