Wydajność#
vCLU jest zaprojektowane dla ograniczonego sprzętu – Raspberry Pi z 512 MB RAM. Pojedynczy proces bez zewnętrznych zależności sprawia, że system jest lekki i przewidywalny.
Zużycie zasobów#
| Zasób | Wartość |
|---|---|
| Rozmiar binarki | ~13 MB |
| RAM minimum | ~13 MB (RPi 1, tryb bare minimum) |
| RAM typowy | 30–50 MB (pełna konfiguracja z HomeKit, MQTT, pluginami) |
| CPU w spoczynku | <1% |
| CPU podczas discovery | ~5% (skanowanie sieci Grenton) |
| Dysk | ~10 MB (binarka + dane konfiguracyjne) |
Obsługiwany sprzęt#
| Urządzenie | Status | Uwagi |
|---|---|---|
| Raspberry Pi 4 | Zalecany | Najlepsza wydajność, 1–8 GB RAM |
| Raspberry Pi 3 B+ | Wspierany | Wystarczający dla typowych instalacji |
| Raspberry Pi Zero 2 W | Wspierany | Kompaktowy, quad-core, 512 MB RAM |
| Raspberry Pi Zero W | Wspierany | Wolniejszy start, single-core, działa stabilnie |
| Raspberry Pi 1 | Minimum | 512 MB RAM, testowane – działa z ograniczeniami |
Architektura ARM64 (aarch64) jest preferowana. Wersja ARM32 (armv6l) działa na starszych modelach Pi.
Metryki systemowe#
vCLU zbiera metryki co 1 minutę i przechowuje je przez 24 godziny. Dostępne są w panelu webowym (zakładka Stats) oraz przez endpoint Prometheus.
System#
| Metryka | Opis |
|---|---|
| Pamięć (MB) | Zużycie pamięci procesu |
| Goroutines | Liczba aktywnych gorutyn |
| GC pause | Czas ostatniej pauzy garbage collectora |
Lua#
| Metryka | Opis |
|---|---|
| Executions | Liczba wykonań kodu Lua |
| Errors | Błędy w callbackach Lua |
| Avg exec time | Średni czas wykonania callbacka |
| Timers | Liczba aktywnych timerów |
MQTT#
| Metryka | Opis |
|---|---|
| Connected | Liczba podłączonych klientów |
| Published | Opublikowane wiadomości |
| Received | Odebrane wiadomości |
| Reconnects | Liczba ponownych połączeń |
HTTP#
| Metryka | Opis |
|---|---|
| Total requests | Wszystkie żądania HTTP |
| API requests | Żądania do endpointów /api/ |
| Web requests | Żądania stron panelu |
| Errors | Odpowiedzi z kodem 4xx/5xx |
| Rate | Żądania na sekundę |
HomeKit#
| Metryka | Opis |
|---|---|
| Accessories | Zarejestrowane akcesoria |
| Paired | Sparowane urządzenia Apple |
| Get / Set / Events | Operacje odczytu, zapisu i powiadomień |
MCP (agent AI)#
| Metryka | Opis |
|---|---|
| Requests | Żądania od agentów AI |
| Errors | Błędy przetwarzania |
| Sessions | Aktywne sesje MCP |
| Latency buckets | Rozkład czasów odpowiedzi |
Endpoint Prometheus#
Metryki dostępne są pod adresem:
GET /metricsFormat odpowiedzi jest kompatybilny z Prometheus. Można go podłączyć do Grafany lub dowolnego systemu monitoringu. Endpoint wymaga uwierzytelnienia (sesja lub klucz API).
Optymalizacje wydajności#
Jeden proces, zero zależności#
vCLU nie wymaga zewnętrznego brokera MQTT, bazy danych ani kontenera Docker. Wszystko działa w ramach jednego procesu – eliminuje to narzut komunikacji międzyprocesowej i upraszcza diagnostykę.
Sekwencyjne wykonanie Lua#
Maszyna wirtualna Lua działa w dedykowanej gorutynie z kolejką zadań. Callbacki wykonują się jeden po drugim, co eliminuje wyścigi danych bez kosztu blokad (mutex). Szczegóły w rozdziale Wielozadaniowość.
Optymistyczne aktualizacje stanu#
Obiekty Remote* (RemoteSwitch, RemoteDimmer, RemoteRoller) ustawiają lokalny cache natychmiast po wywołaniu komendy. Subskrypcja CLU potwierdza lub koryguje stan później. Dzięki temu dashboard reaguje natychmiast, bez czekania na odpowiedź z modułu Grenton.
sequenceDiagram
participant U as Użytkownik
participant V as vCLU (cache)
participant G as Grenton CLU
U->>V: switchOn()
V->>V: _lastState = 1 (natychmiast)
V->>G: set(1) — fire-and-forget UDP
V->>U: Dashboard pokazuje ON
G-->>V: Subskrypcja potwierdza stan 1Fire-and-forget UDP#
Komendy sterujące (set, execute) wysyłane są przez __go_send_command_noreply – pakiet UDP bez oczekiwania na odpowiedź. Eliminuje to blokowanie maszyny Lua na czas round-tripu sieciowego (~10–50 ms na komendę).
Odświeżanie subskrypcji#
Zamiast niszczenia i ponownego tworzenia subskrypcji co 30 sekund (34 blokujące wywołania UDP), system używa clientRefresh – jednego pakietu odświeżającego sesję (17 wywołań, fire-and-forget). Czas odświeżania spadł z 2–3 sekund do kilku milisekund.
Polling GPIO#
Piny wejściowe GPIO odpytywane są co 50 ms z kolejką zdarzeń. Zmiany stanu trafiają do kolejki Lua jako eventy, nie blokując głównej pętli przetwarzania.
Diagnostyka wydajności#
Jeśli system reaguje wolno:
- Sprawdź zakładkę Stats w panelu – sekcja Lua pokaże średni czas wykonania callbacków
- Poszukaj ostrzeżeń w logach o callbackach przekraczających timeout
- Sprawdź liczbę aktywnych timerów – zbyt wiele (>1000) może spowalniać cykl
- Sprawdź bufor MQTT – przy >1000 oczekujących wiadomości system odrzuca najstarsze