# Wydajność

> Jak parser radzi sobie z logami o rozmiarze 100 MB bez obciążania pamięci serwera oraz co możesz zrobić, aby utrzymać szybkie konwersje.

---

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

---

Logi debugowania DNS na ruchliwym kontrolerze domeny są duże. `Convert-DNSDebugLogFile` został stworzony właśnie na takie przypadki: był testowany na logach o rozmiarze 100 MB i większych, i przetwarza je w ciągu kilku minut na zwykłym sprzęcie serwerowym.

## Dlaczego jest szybki

Nie musisz tego wiedzieć, aby korzystać z modułu, ale wyjaśnia to zachowanie, które zaobserwujesz.

| Technika | Efekt, który zauważysz |
|---|---|
| `StreamReader` / `StreamWriter` z buforami 64 KB | Plik jest czytany i zapisywany w kawałkach, zamiast jednym dużym `Get-Content` |
| Strumieniowe przetwarzanie, pojedynczy przebieg | Zużycie pamięci pozostaje mniej więcej stałe, niezależnie od rozmiaru logu |
| Operacje na stringach (`.Substring()`, `.IndexOf()`) zamiast wyrażeń regularnych | Znacznie mniej obciążenia CPU na linię, a linii jest miliony |
| Ręczne zapisywanie CSV zamiast `Export-Csv` | Brak narzutu obiektowego potoku na rekord |
| Agregacja statystyk oparta na hashtable | Podsumowania kosztują prawie nic dodatkowo podczas tego samego przebiegu |

Ważna konsekwencja: **cały log nigdy nie jest trzymany w pamięci.** Log o rozmiarze 500 MB nie wymaga 500 MB RAM. To różnica między modułem a podejściem „wczytaj plik, podziel, zbuduj obiekty”, które stosuje większość domowych skryptów — to podejście działa dobrze na próbce 5 MB, ale zawodzi na prawdziwym DC.

## Jak wycisnąć maksimum z uruchomienia

### Konwertuj obroty, nie jeden gigantyczny plik

Skonfiguruj serwer DNS, aby obracał log przy rozsądnym rozmiarze — 50 do 200 MB to dobry zakres. Kilka średnich plików konwertuje się w przewidywalnym czasie i pozwala zadaniu zaplanowanemu zakończyć się w wyznaczonym oknie. Jeden ciągle rosnący plik w końcu tego nie zrobi.

Obrót daje też zamknięte pliki do pracy, co i tak jest pożądane:

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

### Pomijaj szczegółowe parsowanie, gdy nie jest potrzebne

Jeśli serwer DNS zapisuje pełne szczegóły pakietów, zamiana tych bloków na JSON jest najdroższą częścią konwersji.

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

Spodziewaj się 30–50% szybszych uruchomień na logach zawierających wiele bloków szczegółów, a także znacznie mniejszego pliku CSV. Nadal otrzymujesz dane na poziomie zapytań oraz nagłówek szczegółów TCP/UDP w `Information`. Zobacz [Parametry i opcje](../03-parameters-and-options/).

### Filtruj wcześnie

`-ContextFilter Packet` odrzuca notatki i zdarzenia serwera zanim zostaną zapisane. Mniej danych wyjściowych oznacza mniej operacji I/O, mniejsze pliki i mniej pracy dalej w procesie.

### Proś tylko o to, czego potrzebujesz

`-OutputType Statistic` pomija całkowicie zapis CSV na poziomie wierszy. Jeśli twój dashboard pokazuje tylko dzienne liczniki, to zdecydowanie najtańsza opcja.

### Konwertuj lokalnie, potem przenieś wyniki

Moduł czyta ścieżki SMB/UNC, ale przesyłanie surowego logu 200 MB przez sieć do centralnego parsowania jest wolne. Konwertuj na serwerze DNS, a potem przenieś (skompresowany) CSV — zwykle to jedna dziesiąta bajtów. To jest pomysł stojący za [przykładem zbierania danych sterowanym GPO](../examples/gpo-driven-collection/).

### Kompresuj do transferu i archiwizacji

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

CSV tego typu zwykle kurczy się o 90% lub więcej. Kompresja kosztuje trochę CPU na końcu uruchomienia, ale oszczędza dużo miejsca na dysku i transferu sieciowego.

## Gdy uruchomienie jest wolniejsze niż oczekiwano

Sprawdź kolejno:

1. **Dysk, nie CPU.** Konwersja jest intensywna pod względem I/O. Log na zajętym wolumenie lub czytany przez wolne łącze zdominuje czas działania.
2. **Bloki szczegółów.** Jeśli log zawiera pełne szczegóły pakietów i nie użyłeś `-NoDetailsParsing`, tam idzie czas.
3. **Rozmiar pliku.** Jeden wielogigabajtowy log i tak zajmie trochę czasu. Rozwiązuj to przez obrót, nie parametry.
4. **Antywirus.** Skanowanie w czasie rzeczywistym zarówno źródłowego logu, jak i wygenerowanego CSV może podwoić koszt I/O. Wykluczenie katalogu logów to powszechna i rozsądna praktyka.
5. **Presja pamięci.** Moduł działa strumieniowo, więc nie powinien być przyczyną — ale serwer już wymieniający pamięć na dysk spowolni wszystko.

Więcej objawów i rozwiązań znajdziesz w [Rozwiązywaniu problemów](../08-troubleshooting/).