Wydajność i dobór serwerów

Ile osób jednocześnie obsługuje instancja Archestack, jakich serwerów do tego potrzebuje i ile przestrzeni roboczych mieści jeden serwer bazy danych. Każdą liczbę na tej stronie zmierzono w testach obciążeniowych 23 września 2026 roku, w których symulowane osoby logowały się i pracowały w aplikacji. Żadna z nich nie jest prognozą: większą instalację dobiera się w całych blokach o przetestowanej wielkości.

W skrócie

Wszystkie te wyniki dotyczą pracy z wyłączonymi aktualizacjami na żywo. Gdy są włączone, a tak jest domyślnie, jedna przestrzeń robocza działa komfortowo do około 100 osób jednocześnie.

Jak przebiegają testy

• Osoby. Każda symulowana osoba loguje się na własne konto i przechodzi przez listy, rekordy, wyszukiwania, zapisy i dashboard, robiąc między kliknięciami średnio 6 sekund przerwy. Jedna czwarta z nich korzysta z buildera, reszta z opublikowanej aplikacji. "Osoby jednocześnie" to osoby, które klikają w tym samym czasie, a nie konta.
• Etapy. Przez 45 sekund dochodzą kolejne osoby, a potem ich liczba jest utrzymywana przez 3 minuty. Każdy wynik pochodzi z tych stabilnych 3 minut.
• Szybko. Etap uznaje się za szybki, gdy 95% wczytań stron kończy się w ciągu 1 sekundy, a mniej niż 1% żądań kończy się błędem. Wczytanie strony liczy się od kliknięcia do ostatniej porcji danych na stronie.
• Maszyna. Jeden komputer stacjonarny z procesorem Intel Core i9-12900KF i 96 GB pamięci. Każdy serwer działał w kontenerze z własnymi rdzeniami procesora, a generator obciążenia również miał własne rdzenie. PostgreSQL 16, PgBouncer 1.25 tam, gdzie był używany, limity żądań włączone.

Jedna przestrzeń robocza, wiele osób

Jedna firma, w której wszyscy pracują w tej samej przestrzeni roboczej, zawierającej 2 500 klientów, 25 000 zamówień i 75 000 pozycji zamówień, na serwerze aplikacji z 4 rdzeniami i serwerze bazy danych z 2 rdzeniami:

Powyżej 1 000 osób generatorowi obciążenia zabrakło mocy procesora, więc limitu jednej przestrzeni roboczej nie znaleziono. Przy 1 000 osób żaden z serwerów nie wykorzystywał całego rdzenia.

Aktualizacje na żywo

Domyślnie każdy zapisany wiersz jest wysyłany do każdego otwartego ekranu, który go pokazuje, a każdy z tych ekranów ponownie wczytuje swój rekord, powiązane z nim listy i ich etykiety. Ten koszt rośnie proporcjonalnie do kwadratu liczby osób w przestrzeni roboczej. Na tej samej wersji i tych samych serwerach około 100 osób jednocześnie pracowało komfortowo przy włączonych aktualizacjach na żywo, wobec 1 000 przy wyłączonych; przy 200 osobach 86% wszystkich żądań stanowiły te ponowne wczytania.

Wyłącz je, ustawiając Realtime__EntityChanges=false na serwerze aplikacji. Otwarte ekrany pokażą wtedy zmianę wprowadzoną przez współpracownika przy następnym wczytaniu. Zapisywanie, wyszukiwanie, powiadomienia i informacja o tym, kto jeszcze jest na stronie, działają jak wcześniej. Każda inna liczba na tej stronie dotyczy pracy z wyłączonymi aktualizacjami na żywo.

Wiele firm w jednej instancji

Firmy liczące po 100 osób, każda jako przestrzeń robocza z własną kopią aplikacji (500 klientów, 5 000 zamówień i 15 000 pozycji zamówień), na serwerach w dwóch rozmiarach:

Pierwsza liczba każdej pary dotyczy serwera aplikacji, druga serwera bazy danych. Orientacyjnie 1 000 osób jednocześnie wykorzystuje około połowy rdzenia aplikacji i połowy rdzenia bazy danych.

Gdzie kończą się możliwości jednego serwera bazy danych

Przy bezpośrednim połączeniu każda przestrzeń robocza utrzymuje własne pule połączeń, które rosną wraz z obciążeniem. Przy 5 000 osób serwer bazy danych z pary 4 + 4 doszedł do prawie 2 000 połączeń i wczytywanie stron się załamało; para 6 + 6 w ogóle się nie ustabilizowała. Przez PgBouncer w trybie transakcyjnym bazy danych przestrzeni roboczych korzystają ze wspólnych pul, po kilka połączeń każda: para 4 + 4 obsłużyła wtedy 4 000 osób, z 95% stron w ciągu 54 ms, przy 400 połączeniach, a para 8 + 8 utrzymała 8 000 osób przy 757. Ten test pary 8 + 8 dzielił rdzenie komputera z generatorem obciążenia, więc pokazuje tylko połączenia i nie służy do doboru serwerów.

Serwery dla większej liczby osób

Blok to przetestowana para: serwer aplikacji z 4 rdzeniami i serwer bazy danych z 4 rdzeniami oraz PgBouncer, liczona na 4 000 osób, żeby zostawał pewien zapas. Większą instalację rozbudowuje się o całe bloki.

Obecnie każdy blok jest osobnym wdrożeniem, a firma działa na jednym bloku. Rozłożenie firm na kilka bloków pod jednym adresem i z jednym logowaniem nie zostało jeszcze zbudowane.

Wiele przestrzeni roboczych na jednym serwerze bazy danych

Osobny test dodawał kolejne przestrzenie robocze na jednym serwerze bazy danych, aż do 5 000, przy czym w każdej chwili używanych było 50 z nich:

• Brak błędów. 5 000 przestrzeni roboczych bez żadnej nieudanej rejestracji ani nieudanego żądania.
• Bezczynność nic nie kosztuje. Przestrzeń robocza, której nikt nie używa, nie utrzymuje żadnego połączenia z bazą danych. Po sześciu minutach bez użycia wszystkie 5 000 utrzymywały łącznie 3 połączenia.
• Nowa przestrzeń robocza w ciągu około sekundy. Mediana 0,9 sekundy, łącznie z utworzeniem i przygotowaniem obu baz danych.
• Około 18 MB miejsca na dysku na przestrzeń roboczą: dwie bazy danych i mała aplikacja, nie licząc Twoich własnych danych.

Liczba utrzymywanych połączeń pozostaje na stałym poziomie niezależnie od liczby przestrzeni roboczych, bo połączenia utrzymują tylko te, które są używane. Dwie rzeczy rosną jednak wraz z liczbą przestrzeni roboczych: pamięć serwera aplikacji i czas, jaki mija od restartu, zanim API znów zacznie odpowiadać; przy 5 000 przestrzeni roboczych doszedł on do prawie czterech minut. Planuj restarty dużej instancji z uwzględnieniem tego czasu.

Ustawienia, od których zależą te liczby

• Aktualizacje na żywo wyłączone: Realtime__EntityChanges=false na serwerze aplikacji, zobacz wyżej.
• Pamięć współdzielona bazy danych: shm_size: 1g w kontenerze PostgreSQL. PostgreSQL przechowuje statystyki każdej bazy danych w pamięci współdzielonej, około 55 KB na bazę, a Docker daje kontenerowi 64 MB, jeśli nie ustawi się inaczej. 1 GB wystarcza na około 9 000 przestrzeni roboczych.
• Pula połączeń: PgBouncer w trybie transakcyjnym, z wieloznacznym wpisem bazy danych (wildcard), dzięki któremu nowa przestrzeń robocza nie wymaga żadnej konfiguracji, 2 połączenia na bazę danych i 1 w rezerwie, oraz z limitem połączeń z serwerem wynoszącym co najmniej 4 na aktywną firmę i niższym niż max_connections w PostgreSQL. Przy ciaśniejszym limicie PgBouncer zamyka połączenia jednej firmy, żeby otworzyć połączenia innej: 400 połączeń dla 150 firm doprowadziło przez to ciągłe przełączanie do pełnego obciążenia obu serwerów. Connection stringi serwera aplikacji zawierają No Reset On Close=true. Synchronizacja danych z innymi systemami używa tabel tymczasowych, których pula w trybie transakcyjnym nie zachowuje, więc nadal potrzebuje bezpośredniego połączenia.
• Konserwacja bazy danych: przy tysiącach baz danych dłuższy autovacuum_naptime rozkłada w czasie przebiegi, które PostgreSQL sam wykonuje w każdej bazie danych.

Czego te liczby nie obejmują

• Procesory w chmurze. Wirtualny procesor w chmurze jest zwykle wolniejszy niż rdzeń tego procesora do komputerów stacjonarnych.
• Sieć i przeglądarka. Czasy stron nie obejmują sieci między serwerami a Twoimi użytkownikami ani czasu, jakiego przeglądarka potrzebuje na narysowanie strony.
• Cięższe aplikacje. Strony z większą liczbą powiązanych list albo z większymi tabelami kosztują więcej na stronę niż strony aplikacji testowej.
• Powyżej 10 000 osób. Nic tutaj nie jest ekstrapolowane poza przetestowaną wielkość.

Co dalej

Strona Przestrzenie robocze i hosting wyjaśnia, jak wybrać między jedną a kilkoma przestrzeniami roboczymi na instancję, i opisuje dwa sposoby uruchamiania kontenerów.