2.0 KiB
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— PASSnode tests/mention-autocomplete-test.mjs— PASSnode tests/mention-navigation-test.mjs— PASSnode --check static/js/*.js(osobno dla plików) — PASScargo 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.