# Performance

> How the parser handles 100 MB logs without eating your server's memory, and what you can do to keep conversions fast.

---

LLMS index: [llms.txt](/llms.txt)

---

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:

```powershell
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.

```powershell
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](../03-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](../examples/gpo-driven-collection/).

### Compress for transfer and archive

```powershell
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:

1. **Disk, not CPU.** Conversion is I/O-heavy. A log sitting on a busy volume, or read over a slow link, dominates the runtime.
2. **Detail blocks.** If the log contains full packet details and you did not use `-NoDetailsParsing`, that is where the time goes.
3. **File size.** A single multi-gigabyte log will take a while regardless. Fix this with rollover, not with parameters.
4. **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.
5. **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](../08-troubleshooting/).