Wydajność socket.io Opcje

[Skie]

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:

Kod

var app = require('express')();
var http = require('http').Server(app);
var io = require('socket.io')(http);

app.get('/', function(req, res) {
    res.sendfile(__dirname  + '/index.html');
});

io.on('connection', function(socket) {
    socket.emit('connection');
    socket.on('req', function() {
        socket.emit('ans', 'hello');
    });
});

http.listen(3000, function() {
    console.log('listening on *:3000');
});

Client

Kod

var socket = io();
var cnt = 0;
var startTime = 0;
var endTime = 0;

socket.on('ans', function(message) {
    if (++cnt === 10000) {
        endTime = performance.now();
        console.log(endTime-startTime);
    }
});
    
socket.on('connection', function() {
    startTime = performance.now();

    for (var i=0; i<10000; i++) {
        socket.emit('req', 'hello');
    }    
});

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

[by_ikar]

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ł.

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ń.

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ś.

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

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.

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.