Maksymalna liczba jednoczesnych połączeń Socket.IO


124

To pytanie zostało zadane wcześniej, ale nie niedawno i nie zawierało jasnej odpowiedzi.

Czy używając Socket.io, istnieje maksymalna liczba jednoczesnych połączeń, które można utrzymać, zanim będzie trzeba dodać kolejny serwer?

Czy ktoś zna jakieś aktywne środowiska produkcyjne, które używają gniazd sieciowych (szczególnie socket.io) na masową skalę? Naprawdę chciałbym wiedzieć, jaki rodzaj konfiguracji jest najlepszy dla maksymalnej liczby połączeń?

Ponieważ Websockets są zbudowane na podstawie TCP, rozumiem, że jeśli porty nie są współdzielone między połączeniami, będziesz ograniczony limitem portów 64K. Ale widziałem też raporty o połączeniach 512K przy użyciu Gretty . Więc nie wiem.


3
Trello korzysta z gniazd na masową skalę (a konkretnie socket.io).
James,

Czytałem, że Trello musiało zmodyfikować kod Socket.io ze względu na ograniczenie liczby połączeń wynoszące 10 000 i było w stanie utrzymać „wiele tysięcy” połączeń przed dodaniem serwerów. Wciąż istnieje ogromna przepaść między tym a 512K innych systemów serwerowych.
Andrew,

1
Ile lat ma ten artykuł? Trello niedawno osiągnął ponad 1 milion aktywnych użytkowników miesięcznie, więc wyobrażam sobie, że mają teraz ponad 10 000 aktywnych gniazd. Trello używa Redis, aby usiąść na górze socket.io dla skalowalności
James,

2
Trello ma teraz najwyraźniej ponad 4 miliony użytkowników, ale z pewnością używają tego na dużej liczbie serwerów, prawda? To sprowadza mnie z powrotem do mojego pierwotnego pytania: jaka jest ich (lub kogokolwiek innego) rzeczywista szczytowa liczba jednoczesnych użytkowników na serwer? Dobrze byłoby również wiedzieć, jakiego rodzaju serwera / kontenera używają. Czy nadal prowadzą swój własny fork, czy też wracają do początku / mistrza? Moim jedynym celem, aby zadać to pytanie, była próba oceny, czy moja firma (w tamtym czasie) mogłaby sobie pozwolić na utrzymanie aplikacji Socket.io dla prawdopodobnie 120000 jednoczesnych połączeń.
Andrew,

1
Jeśli chodzi o limit portu, myślę, że wyjaśnienie, dlaczego nie stanowi to problemu, zostało tutaj wyjaśnione . Zasadniczo jedynym portem używanym w systemie jest ten, na którym nasłuchujesz. Gniazda są tworzone dla każdego połączenia, a te używają deskryptorów plików, ale nie używają portów w twoim komputerze.
Paul Lynch,

Odpowiedzi:


78

Ten artykuł może Ci pomóc: http://drewww.github.io/socket.io-benchmarking/

Zastanawiałem się nad tym samym pytaniem, więc napisałem mały test (przy użyciu odpytywania XHR), aby zobaczyć, kiedy połączenia zaczęły zawodzić (lub pozostawać w tyle). Stwierdziłem (w moim przypadku), że gniazda zaczęły działać przy około 1400-1800 jednoczesnych połączeniach.

Oto krótkie podsumowanie, które zrobiłem, podobne do testu, którego użyłem: https://gist.github.com/jmyrland/5535279


7
Zdaję sobie sprawę, że jest to starszy temat, ale znalazłem go jako pierwszy podczas wyszukiwania pytania do mojej odpowiedzi i ostatecznie odkryłem, że jest to pomocne: rtcamp.com/tutorials/linux/increase-open-files-limit Limit otwartych plików na proces może domyślnie jest to miękki limit 1024 i twardy limit 4096, a ponieważ każdy otwarty port TCP reprezentuje plik, ważne jest, aby wziąć pod uwagę te limity przy określaniu, na ile otwartych gniazd maszyna pozwoli na maksymalne wykorzystanie biblioteki.
DeeperID

2
@JAM Czy kiedykolwiek odkryłeś, dlaczego gniazda sieciowe działały z około 1400-1800 połączeniami? Mam identyczny problem, a moje limity plików są ustawione na 100 000, więc wiem, że to nie jest problem. Każda pomoc byłaby bardzo mile widziana. Dziękuję Ci.
Seth

@seth: minęło trochę czasu, odkąd ostatnio przeglądałem to, ale myślę, że taki był wniosek: sondaże XHR pochłonęły zbyt dużo zasobów (w porównaniu z innymi metodami transportu). W przypadku korzystania z gniazd sieciowych liczba jednoczesnych połączeń była wyższa.
JAM

@JAM dziękuję za odpowiedź. Widzę te same problemy przy użyciu modułu WS, a nie socket.io, więc nie powinno być żadnego odpytywania XHR z modułem ws. W tym miejscu mam problemy z rozwiązywaniem problemów. Poszukiwanie trwa.
Seth

To jest dobra, czysta odpowiedź. Również poprawna, ponieważ jest to przypadek po przypadku. Osobiście sugeruję ppl napisanie własnych testów porównawczych lub symulatora połączeń. Chociaż test dla kogoś innego może być dobry, nie reprezentuje rzeczywistego środowiska ... Gdy masz już symulator klienta, który może obsłużyć dowolną liczbę klientów z różnymi błędami w świecie rzeczywistym. Możesz wykonać test porównawczy po dużych zmianach, a także aktualizuj swój symulator na bieżąco. Obsługa interfejsu czatu użytkownika różniłaby się od monitorowania przeglądarki użytkownika i tak dalej. Python, który uważam za bardzo przydatny w skryptowaniu symulatora ...
Angry 84

16

Próbowałem użyć socket.io na AWS, mogę maksymalnie utrzymać około 600 stabilnych połączeń.

I dowiedziałem się, że to dlatego, że socket.io najpierw używał długiego odpytywania, a później zaktualizował do Websocket.

po ustawieniu konfiguracji tak, aby korzystała tylko z Websocket, mogę utrzymać około 9000 połączeń.

Ustaw tę konfigurację po stronie klienta:

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })

2
czy użyłeś EC2, jakiego rodzaju instancji? t2.micro, t2.nano?
bvdb

2
Czy zauważyłeś różnicę w responsywności, kiedy wymuszasz websockets?
Lauren,

Czy wiesz, jaki rozmiar miała Twoja instancja? Również po to, aby każdy w przyszłości wiedział, że niektóre stare przeglądarki nie obsługują WebSockets, dlatego aktualizacja może być ważna dla niektórych.
Ryan Soderberg

Jak możemy sprawdzić, ile połączenia obsługuje serwer? Jak zmierzyłeś to 9000 połączeń? Proszę zasugerować ..
Ciekawy programista


6

Dla + 300k jednoczesnego połączenia:

Ustaw te zmienne w /etc/sysctl.conf:

fs.file-max = 10000000 
fs.nr_open = 10000000

Zmień również te zmienne w /etc/security/limits.conf:

* soft nofile 10000000
* hard nofile 10000000
root soft nofile 10000000
root hard nofile 10000000

I wreszcie, zwiększ też bufory TCP /etc/sysctl.conf:

net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

więcej informacji można znaleźć pod adresem https://www.linangran.com/?p=547


jak sprawdzić, czy nasze zmiany działają?
Ciekawy deweloper
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.