# Rustpad 0.2.88 — wyniki testów wydajności

Zmiana: w `src/websocket/pad.rs` i `src/websocket/mod.rs` ograniczono sprawdzanie dostępu przy przychodzących zdarzeniach broadcast do najwyżej jednego sprawdzenia na sekundę na połączenie. Kontrola cykliczna i zdarzenia zmiany hasła pozostają aktywne. W zestawie pozostają optymalizacje renderowania z poprzedniej iteracji.

## Symulacja deterministyczna (Node.js)

Założenia: 10 s, 2 edycje/s na użytkownika, każda edycja rozsyłana do wszystkich N odbiorców (w tym nadawcy), bez rzeczywistej sieci, bazy danych, WebSocket czy renderowania. Symulacja porównuje liczby sprawdzeń dostępu, a **nie** rzeczywistą przepustowość ani opóźnienia Rustpada.

| Użytkownicy | Dostawy zdarzeń | Sprawdzenia przed | Sprawdzenia po | Redukcja |
|---:|---:|---:|---:|---:|
| 5 | 500 | 500 | 50 | 90,00% |
| 100 | 200 000 | 200 000 | 1 000 | 99,50% |
| 300 | 1 800 000 | 1 800 000 | 3 000 | 99,83% |
| 500 | 5 000 000 | 5 000 000 | 5 000 | 99,90% |

Uruchomienie: `node tests/broadcast-load-simulation.mjs`.

## Testy

- `node tests/feature-smoke-test.mjs` — PASS
- `node tests/mention-autocomplete-test.mjs` — PASS
- `node tests/mention-navigation-test.mjs` — PASS
- `node --check static/js/*.js` (osobno dla plików) — PASS
- `cargo test` — NIEURUCHOMIONY (brak Rust/cargo w środowisku)
- Test end-to-end z setkami aktywnych przeglądarek i prawdziwym WebSocket/PostgreSQL — NIEURUCHOMIONY.

## Ograniczenia

Nie można zagwarantować płynnej pracy kilkuset użytkowników bez testu na docelowym sprzęcie i bazie. Każdy zapis nadal przechodzi przez serializację zmian i trwałe utrwalenie w bazie; duża liczba operacji może nasycić bazę i sieć. Zmiana odświeżania uprawnień może wydłużyć wykrycie odwołania dostępu w trakcie ciągłego broadcastu do około 1 sekundy; istniejący timer kontroli okresowej pozostaje. Wersja 0.2.88 jest wydaniem z nową poprawką na życzenie użytkownika i nie należy jej mylić z wcześniej wydaną paczką 0.2.88.