# Prestazioni

> Come il parser gestisce log da 100 MB senza consumare tutta la memoria del server, e cosa puoi fare per mantenere le conversioni veloci.

---

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

---

I log di debug DNS su un controller di dominio molto trafficato sono grandi. `Convert-DNSDebugLogFile` è stato progettato proprio per questo caso: è stato testato con log da 100 MB e oltre, e li elabora in pochi minuti su hardware server ordinario.

## Perché è veloce

Non devi sapere nulla di tutto questo per usare il modulo, ma spiega il comportamento che osserverai.

| Tecnica | Effetto che noterai |
|---|---|
| `StreamReader` / `StreamWriter` con buffer da 64 KB | Il file viene letto e scritto a blocchi invece che con un unico grande `Get-Content` |
| Streaming, singolo passaggio | L’uso di memoria resta più o meno costante indipendentemente dalla dimensione del log |
| Operazioni su stringhe (`.Substring()`, `.IndexOf()`) invece di espressioni regolari | Molto meno CPU per riga, e ci sono milioni di righe |
| CSV scritto a mano invece di `Export-Csv` | Nessun overhead di pipeline oggetti per ogni record |
| Aggregazione basata su Hashtable per le statistiche | I riepiloghi costano quasi nulla durante lo stesso passaggio |

La conseguenza importante: **l’intero log non viene mai caricato in memoria.** Un log da 500 MB non richiede 500 MB di RAM. Questa è la differenza tra il modulo e l’approccio “leggi il file, dividilo, crea oggetti” che la maggior parte degli script fatti in casa usa — quell’approccio funziona bene su un campione da 5 MB ma fallisce su un DC reale.

## Come ottenere il massimo da una conversione

### Converti i chunk ruotati, non un unico file gigante

Configura il server DNS per far ruotare il log a una dimensione gestibile — da 50 a 200 MB è un buon intervallo. Diversi file medi si convertono in tempi prevedibili e permettono a un job schedulato di finire entro la sua finestra. Un file che cresce sempre invece no.

La rotazione ti dà anche file chiusi con cui lavorare, che è quello che vuoi comunque:

```powershell
Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME
```

### Salta il parsing dei dettagli se non ti serve

Se il server DNS scrive dettagli completi dei pacchetti, trasformare quei blocchi in JSON è la parte più costosa della conversione.

```powershell
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -NoDetailsParsing
```

Aspettati esecuzioni dal 30 al 50% più veloci su log che contengono molti blocchi di dettaglio, più un CSV molto più piccolo. Otterrai comunque i dati a livello di query e la riga di intestazione TCP/UDP in `Information`. Vedi [Parametri e Opzioni](../03-parameters-and-options/).

### Filtra presto

`-ContextFilter Packet` scarta note ed eventi del server prima che vengano scritti. Meno output significa meno I/O, file più piccoli e meno lavoro a valle.

### Chiedi solo ciò che ti serve

`-OutputType Statistic` salta completamente la scrittura del CSV a livello di riga. Se la tua dashboard mostra solo conteggi giornalieri, questa è di gran lunga l’opzione più economica.

### Converti localmente, sposta i risultati

Il modulo legge percorsi SMB/UNC, ma trasferire un log grezzo da 200 MB in rete per analizzarlo centralmente è il modo più lento. Converti sul server DNS, poi sposta il CSV (compresso) — di solito è un decimo dei byte. Questo è il design dietro l’[esempio di raccolta guidata da GPO](../examples/gpo-driven-collection/).

### Comprimi per trasferimento e archivio

```powershell
Convert-DNSDebugLogFile -InputFile "C:\Logs\dns.log" -CompressOutput
```

Un CSV di questa forma tipicamente si riduce del 90% o più. La compressione costa un po’ di CPU alla fine della conversione e risparmia molto spazio su disco e rete dopo.

## Quando una conversione è più lenta del previsto

Controlla questi punti in ordine:

1. **Disco, non CPU.** La conversione è intensiva in I/O. Un log su un volume molto occupato, o letto su un collegamento lento, domina il tempo di esecuzione.
2. **Blocchi di dettaglio.** Se il log contiene dettagli completi dei pacchetti e non hai usato `-NoDetailsParsing`, lì va il tempo.
3. **Dimensione del file.** Un singolo log multi-gigabyte richiederà comunque tempo. Risolvi con la rotazione, non con i parametri.
4. **Antivirus.** La scansione in tempo reale sia del log sorgente che del CSV generato può raddoppiare il costo effettivo di I/O. Un’esclusione per la cartella dei log è una misura comune e ragionevole.
5. **Pressione sulla memoria.** Il modulo usa lo streaming, quindi non dovrebbe essere la causa — ma un server già in swapping rallenterà tutto.

Altri sintomi e soluzioni sono raccolti in [Risoluzione dei problemi](../08-troubleshooting/).