Forum PHP.pl

Hej,
testuje sobie dzisiaj wydajność interfejsów websocket dostępnych w róznych językach programowania i trafiłem na problem z socket.io. Napisałem sobie prosty skrypcik, który ma mi zmierzyć czas przesyłania 10 tys. żądań ws. Niestety używając tego skryptu dostaję mierne wyniki rzędu ~1.500 req/s. Przy analogicznym teście z użyciem ratchet w PHP dostaję wyniki ~27.5 tys., czyli prawie 20 razy więcej. Dodatkowo test samego protokołu HTTP w js daje mi wynik prawie 4 tys. żądań. Całość wygląda jakby każde żądanie socket.io nawiązywało nowe połączenie zamiast używać starego, ale zdarzenie connect leci tylko raz, więc to nie powinno być przyczyną. Może mi ktoś powiedzieć co jest w tym teście źle?

Server:


Client


Ten post edytował Skie 21.04.2016, 19:33:20

Node.js działa jedno-wątkowo, więc jeżeli masz na tej maszynie ~8 rdzeni, out of box node ci tego nie obsłuży, dlatego że sposób działania node.js jest inny od tego jak działa PHP. Dla PHP każdy request to jest nowy wątek, w przypadku node.js takie coś trzeba sobie dorobić samemu, bo nie jest to aplikacja bezstanowa, jak w przypadku PHP. Sprawdź ile wątków utworzył PHP aby obsłużyć te 27k emitów, i przelicz to na ile jeden wątek jest w stanie udźwignąć takich emitów i będziesz miał porównanie z node.js.

Nie ma czegoś takiego w websocketach jak request, jest emit, jest handshake, w twoim przypadku są to emity. socket.io nie jest "prostą" bilbioteką jak tą którą użyłeś w PHP, tutaj masz takie rzeczy jak namespace, jak roomy, jak możliwość skalowania na wiele maszyn, wciąż korzystając przestrzeni nazw/pokoi. socket.io to również fallback do xhr-poolingu kiedy nie ma websocketów, czy są zablokowane przez jakieś antywirusy czy firewalle (w większości firm admini blokują wszystkie inne protokoły z wyjątkiem http/https). Socket.io to również możliwość przesyłania całych blobów. To dużo więcej niż tylko pub/sub..

Ten post edytował by_ikar 21.04.2016, 22:03:43

@by_ikar, co to znaczy że php jest aplikacją bezstanową ?

To znaczny, że każde żądanie tworzy zupełnie nowe, odseparowane środowisko dla skryptu - jest startowany od zera, wszystko musi się załadować, zainicjować i dopiero wykonać faktyczną obsługę żądania.

Bo ja słyszałem że właśnie to jest przyczyna przeprowadzania udanych ataków typu DDos, ponieważ na każe żądanie PHP musi odpowiedzieć.

Przyczyną każdego udanego ataku DDoS jest limit zasobów sprzętowych, a nie to w jaki sposób dany język/technologia działa.

Atak niweluje się od wejścia a nie na samym dnie...
To tak jakbyś chronił przed kradzieżą w domu dopiero jak ktoś będzie zabierał fanty

Dzięki za wszystkie odpowiedzi, ale wciąż nie dostałem odpowiedzi czemu to tak słabo działa. Wiem o tym wszystkim co piszesz @by_ikar bo piszę tego typu niestandardowe webaplikacje już od dawna, ale akurat nie używałem do tej pory socket.io. Odpowiadajać na Twoje pytanie to PHP obsługuje te 27.5 tys. na jednym wątku i program, który testuje wykorzystuje analogiczną architekturę do node.js, a nie standardowe podejście PHP. Jeśli pozwolę mojej aplikacji testowej na użycie większej ilości wątków i połączę je za pomocą IPC, wraz z narzutem komunikacji na mojej maszynie bez problemu osiagam wyniki ponad 100 tys.

Ale wciaż... to co mnie interesuje to czemu node.js obsługuje tylko 1.5 tys. "emitów" websocket na sekundę na jedynm wątku, jeśli PHP ogarnia 27.5 tys.?
Dodatkowo tak jak pisałem analogiczny test, z użyciem HTTP (ab), również na 1 wątku w node.js daje wynik ~3.9 tys żądań HTTP, a w PHP ~4.9 tys.
Websocket generalnie powinien (po handshake i upgrade) działać znacznie szybciej niż HTTP, więc w przypadku PHP skos z 4.9 na 27.5 tys. ma sens, ale w node.js degradacja z 3.9 tys do 1.5 tys? Co jest w tym teście nie tak? Czy może socket.io jest po prostu tak bardzo wolną biblioteką?

Ten post edytował Skie 22.04.2016, 14:38:44

Tak, ale ja testuje w ten sposób właśnie wydajność wzorca req-rep za pomocą WS od strony przeglądarki, bo to jest rzeczywisty use-case w jakim coś takiego będzie używane. Testowanie asynchronicznego protokołu w jedną stronę nie ma sensu, bo mimo, że jest asynchroniczny to odbiór i wysył wiadomości rzadko kiedy jest symetryczny i zazwyczaj odbiór i wysyłanie działa z różną wydajnością. Trochę źle opisałeś, bo to nie jest tak, że wysyłam żadanie i czekam na odpowiedź, lecz wysyłam od razu wszystkie 10 tys i czekam na 10 tys. zwrotek. I nie ma znaczenia, że to tworzy dodatkowy narzut na wydajność, bo analogicznie testuje przykład z PHP, więc narzut powinien być taki sam. Zwłaszcza, że testy wykonuję lokalnie, więc nie ma mowy o żadnym sieciowym zawijasie jak to dociera do mnie. Aczkolwiek masz rację, że pojęciowo źle się wyraziłem na początku z "żądaniami". Powinienem był jasno zaznaczyć wyniki 1.5 tys. "żądań typu req-rep", czyli samych emitów będzie rzeczywiście 3 tys. Aczkolwiek to samo tyczy się PHP zamiast 27.5 tys req-rep będzie 55 tys. emitów, więc róznica prawie 20x pozostaje.



Dzięki za tę informację, gdyż z takich symulacyjnych narzędzi korzystałem wcześniej z thora, ale nie byłem z niego zadowolony. Niestety problem z tym narzędziem jest taki, że wspiera konkretne subprotokoły ws. W jaki sposób za pomocą tego samego narzędzie mam przetestować np. czysty WS zaimplementowany w PHP czy też w Pythonie? Chyba się nie da, a testy z użyciem różnych narzędzi nie mają sensu, więc odpada to. Potrzebuję czegoś uniwersalnego. Pozostaje test JSowy z klienta jak w pierwszym poście, ale tutaj właśnie socket.io odstaje.



Node.js akurat jest stanowy, więc wydaje mi się, że pisałeś to na szybko i coś Ci się pomieszało. Co masz na myśli, że "każda implementacja będzie szybsza od tego co jest w PHP"? Co znaczy, że PHP Twoim zdaniem zużywa dużo zasobów? Bo podajesz przykład, że socket.io jest bardziej rozbudowany bo ma xhr-pollling, fallbacki, firewalle i inne.... ale no właśnie Ratchet na sterydach też ma to wszystko. Dodatkowo przy odpowiedniej architekturze łatwo uzyskać efekt stanowy tak jak w node.js. Nie czepiam się tutaj, więc nie traktuj tego jako atak, po prostu jestem ciekaw czy coś przegapiłem?

EDIT:
Dodałem analogiczny test dla SockJS z wynikiem ~ 23.725 [req-rep / s]. Jest to wynik zbliżony do PHPowego 27.5 tys i zgodny z różnią wydajności HTTP w Node.js vs PHP7. Błędem było sprawdzanie wydajności czystego WS z socket.io, które jak widać ma swoją cała infrastrukturę pod spodem, a to je spowalnia. Podsumowując, w swoim benchmarku wyrzucam socket.io jako reprezentatna WS z poziomu JS i dam SockJS.

Ten post edytował Skie 22.04.2016, 19:46:46

Tak, masz rację, że nie będę wysyłał 10 tys. emitów z jednego klienta, aczkolwiek czas nawiązywania połączenia i ilość max połączeń testuje tak jak pisałem thorem w osobnych testach. Ten tutaj to po prostu taki test brute force, jak szybko przesyłana jest faktyczna wiadomość po nawiązaniu połączenia.

Sprawdzę jeszcze to co pisałeś z transportem w socket.io z ciekawości, choć tak jak pisałem w testach zostwię SockJS, gdyz jest bliższy temu co mam w PHP, więc test jest bardziej miarodajny. Dzięki za Twój wkład w tym temacie, plusiki za pomoc już poleciały

W wolnej chwili pobawiłem się https://github.com/M6Web/websocket-bench którego również można użyć do zwykłych websocketów, ale dodatkowo ma zaimplementowane kilka innych popularnych implementacji websocketów. Korzystając z twojego przykładu potrzebowałem 1655.41 na wysłanie i odebranie 10k emitów. Kiedy zamykałem narzędzia developerskie, odświeżałem stronę i dopiero otwierałem konsole, wynik bywał lepszy 1517.0100000000002, a czasami nawet 100ms mniej. Ale teraz ci pokażę dlaczego twój test nie jest miarodajny.



10k wiadomości w 4.5 sekundy? Słabo nie ? Pójdźmy dalej i dodajmy trochę więcej wiadomości:



100k wiadomości w 4.5 sekundy? Coś tutaj jest nie tak, według twojego testu, nie powinno takie coś mieć miejsca. Pójdźmy dalej, dodajmy trochę więcej wiadomości:



milion wiadomości w 4.5k sekundy? Zobaczmy jak daleko możemy się posunąć:



10 milionów, czas? Wciąż 4.5 sekundy. Damy radę 100 milionów ?



Damy, czas się nie zmienia, czas odpowiedzi wciąż zbliżony. Ciekawe jak pójdzie z miliardem wiadomości:



No i tutaj już zaczynają się schody, widać że to jest próg.

Mój plik generator.js:



Nie ma sensu sprawdzania ile jedno połączenie jest w stanie przetworzyć wiadomości na sekundę, bo nigdy takiej ilości nie będziesz wysyłać na jednym połączeniu. Jak i nie ma sensu wysyłania emitów które kompletnie nic nie robią, bo czas odpowiedzi to nie wszystko, trzeba jeszcze przesłane dane przerobić, zapisać do bazy, czy też odczytać z bazy, albo przekazać dalej.

Ten post edytował by_ikar 25.04.2016, 13:27:45

Tak, trzeba dane przetworzyć, ale testy wydajnościowe implementacji protokołu wejścia bada się po to by znać narzut jaki ten protokół tworzy na aplikację. To nie są testy wydajnościowe całej aplikacji, tylko samego protokołu. Jeśli Twoim zdaniem, nie ma sensu badanie tego, bo w praktyce aplikacja "coś" musi jeszcze zrobić, to żadne testy wydajnościowe nie mają sensu - ani architektury, ani wejścia-wyjścia, ani komponentów - niczego, bo, po co np. badać ilość żadań HTTP, skoro, przecież serwer oprócz wysłania odpowiedzi musi ją jeszcze przetworzyć? Albo po co badać wydajność jak szybko serwer przetworzy jakiś template skoro dane do niego potrzebuje zbazy? I po co bazę testować, skoro przecież te dane i tak trzeba przetworzyć a nie tylko pobrać? Wybacz, ale to co zaczynasz mówić powoli traci sens - najpierw zarzucasz, że przedstawiony w pierwszym temacie test nie ma sensu, bo czeka na odpowiedź i tworzy narzut wydajnościowy z tego względu, a potem dajesz przykład bez czekania i wysyłanie pustych emitów i mówisz, że to z kolei jest złe, bo oprócz wysłania wiadomości serwer coś będzie robił.

Co do testu, który pokazałeś i setki tysiące czy miliony wiadomości, które zdążyłeś wysłać w teście to ten test jest znacznie gorszy niż czekanie na odpowiedź, którą skrytykowałeś. Node.js jest aplikacją wysokopoziomową, ale same gniazda nieważne jak zaawansowane czy to proste TCP, czy WS czy coś fajniejszego jak Zmq w praktyce wszystko ląduje w jakimś buforze C++. Zazwycaj te implementacje zwracają sukces wg swojego interfejsu po przesłaniu danych do bufora i czekają z wysokim priorytetm na moment aż interpreter czy maszyna wirtualna będzie miała trochę czasu, by wiadomości naprawdę przesłać. W praktyce tak jest najwydajniej i są to wiadomo mikro czy nanosekundy opóźnienia, ale skoro Twój test polega tylko na wysłaniu emitu i stweirdzeniu "ok, koniec testu", to w praktyce, w momencie jak test się kończy aplikacja może wciąż mieć masę wiadomości do wysłania "pod spodem". To co mnie interesuje przy testowaniu protokołu to ilość wiadomości wysłanych na sekundę wraz z odbiorem odpowiedzi dla każdej z nich, bo wiem, wtedy czego w rzeczywistości mogę oczekiwać. Oczywiście różne protkoły, mają dodatkowe parametry jak czas nawiązania połączenia, opóźnienie, max. ilość jednoczesnych połączeń i inne i też są te dane ważne. Ale dla każdych z nich warto stworzyć osobny scenariusz testowy.

Ten post edytował Skie 25.04.2016, 17:08:45

Nie wyraziłem się zbyt jasno za pierwszym razem, z czym później się poprawiłem, pisząc że nie będziesz testował pustych emitów, jak i aplikacja zupełnie inaczej się skaluje w przypadku kilkuset połączeń.


Użyj tego samego testu i przetestuj wersję w PHP i porównaj wyniki.


Kiedy wiadomość jest nie wysłana, bo można sprawdzić czy została wysłana, jest wyzwalany error, z informacją że wiadomość nie została wysłana. Skoro nie ma błędów, a czas wysyłania nie zwiększył się (2 przedostatnie testy) wiadomość jest natychmiastowo przetwarzana. W momencie kiedy event loop się zapycha i zamiast przetwarzać kolejne rzeczy, wrzuca je do kolejki, wtedy zaczynają się pojawiać opóźnienia (ostatni test). Jeżeli jest brak błędów, wiadomości zostały przetworzone, ale ten próg można przekroczyć i wtedy będą się pojawiać błędy, połączenia będą zrywane etc bo zwyczajnie serwer nie będzie w stanie przetworzyć nic więcej, bo będzie zapchany.

Jeden z fajniejszych feature socket.io to jest możliwość skalowania go pomiędzy procesami/maszynami w dość łatwy sposób. A sama możliwość skalowania, otwiera możliwość do komunikacji pomiędzy socket.io a nie websocketowymi interfejsami. Przykładowo wysyłanie broadcasta do określonego pokoju z poziomu PHP, czy wielu innych dostępnych adapterów. Gdyby te wszystkie rzeczy w PHP były i działały tak super fajnie, to te największe firmy nie przerzucałby się z php na node.js + któraś implementacja websocketów.