2015-02-19 28 views
13

Potrzebuję stałego dostępu do serwera, aby uzyskać aktualne dane dotyczące instrumentów finansowych. Cena ciągle się zmienia, więc muszę prosić o nowe ceny co 0,5 sekundy. Interfejsy REST API brokerów pozwalają mi to zrobić, jednak zauważyłem, że podczas łączenia się z serwerem występuje pewne opóźnienie. Właśnie zauważyłem, że oni też mają websocket API chociaż. Zgodnie z tym, co przeczytałem, obaj mają pewne plusy/minusy. Ale za to, co chcę robić i ponieważ prędkość jest tutaj szczególnie ważna, jaki rodzaj API poleciłbyś? Czy websocket jest naprawdę szybszy?websocket vs rest API dla danych w czasie rzeczywistym?

Dziękujemy!

+0

Szybkość operacji zależałaby całkowicie od serwera. Jedyną odpowiedzią jest wypróbowanie obu rozwiązań i sprawdzenie, które rozwiązanie najlepiej pasuje do Twojej aplikacji. –

+2

Nie wiem, dlaczego ludzie głosują, aby zamknąć to jako "oparte na opiniach". Istnieją dobre, logiczne, oparte na faktach powody, dla których webSocket jest lepszym wyborem do dostarczania danych w czasie rzeczywistym do klienta niż połączenie Ajax przy użyciu usługi REST. To wcale nie jest opinia - właściwie to właśnie dlatego webSockets zostały zaprojektowane, aby poprawić/rozwiązać ten problem lepiej niż wywołania Ajax. Wszystkie pytania są lepsze niż B nie są oparte głównie na opiniach. Wielu można odpowiedzieć faktami, logiką i odniesieniami, które nie są przede wszystkim opinią. – jfriend00

+12

Głosowanie w celu ponownego otwarcia. Na to pytanie można odpowiedzieć bez odpowiedzi, która brzmi "przede wszystkim odpowiedź oparta na opiniach". Niektórzy ludzie tutaj są zbyt szybcy, by spróbować zamknąć coś, co po prostu pyta, czy A jest lepsze od B, nie rozumiejąc, czy odpowiedź może być dostarczona z faktami, logiką i odniesieniem, a nie tylko z opinią. Spójrz na jedną odpowiedź poniżej i zadaj sobie pytanie, czy ta odpowiedź brzmi "przede wszystkim opinia". Myślę, że nie. Opiera się na faktach, zrozumieniu, w jaki sposób działają dwie opcje i jak można je zastosować do problemu, o który się pytamy. – jfriend00

Odpowiedz

22

Najbardziej efektywną operacją dla tego, co opisujesz, byłoby użycie połączenia webSocket między klientem a serwerem, a serwer powinien przesyłać zaktualizowane informacje o cenach bezpośrednio do klienta przez webSocket TYLKO, gdy cena zmieni się o jakąś znaczącą kwotę lub gdy minie jakaś minimalna ilość czasu i cena się zmieniła.

Może to być o wiele bardziej wydajne niż to, że klient stale prosi o nowe zmiany cen, a czas, w którym nowe informacje docierają do klienta, może być bardziej aktualny.

Jeśli interesuje Cię, jak szybko informacje o nowym poziomie cenowym docierają do klienta, webSocket może uzyskać o wiele więcej czasu, ponieważ serwer może wysłać nowe informacje o cenach bezpośrednio do klienta. bardzo moment zmienia się na serwerze. Podczas korzystania z wywołania REST, klient musi sondować w pewnym ustalonym przedziale czasu i będzie tylko otrzymywać nowe dane w momencie ich interwału odpytywania.

WebSocket może być także szybszy i łatwiejszy w twojej infrastrukturze sieciowej, ponieważ mniej operacji sieciowych jest zaangażowanych w proste wysyłanie pakietów przez już otwarte połączenie WebSocket w porównaniu do tworzenia nowego połączenia dla każdego wywołania REST/Ajax, wysyłania nowych danych, następnie zamknięcie połączenia. Jak duża różnica/udoskonalenie tego sprawia, że ​​w danej aplikacji będzie coś, co musiałbyś zmierzyć, aby naprawdę wiedzieć.

Ale webSockets zaprojektowano tak, aby pomagały w konkretnym scenariuszu, w którym klient chce wiedzieć (tak blisko w czasie rzeczywistym, jak to praktycznie możliwe), gdy coś zmienia się na serwerze, więc zdecydowanie sądzę, że byłby to preferowany wzorzec projektowy dla tego typu użytkowania.


Oto porównanie operacji sieciowych zajmujących się wysyłając zmiany cen na już otwartym websocket vs. wykonanie połączenia spoczynkowego.

websocket

  1. Server widzi, że cena się zmieniła i natychmiast wysyła wiadomość do każdego klienta.
  2. Klient otrzymuje wiadomość o nowej cenie.

Rest/Ajax

  1. Klient ustawia interwał sondowania
  2. podczas następnej Polling Interval spuście, klient tworzy połączenie z gniazdem do serwera
  3. Server odbiera żądanie, aby otworzyć nowe gniazdo
  4. Po nawiązaniu połączenia z serwerem klient wysyła żądanie nowej informacji o cenach do serwera
  5. Serwer otrzymuje prośbę o podanie nowych informacji o cenach i wysyła odpowiedź z nowymi danymi (jeśli istnieją).
  6. Klient otrzymuje nowe dane cenowe
  7. klient zamyka gniazdo
  8. Server odbiera gniazdo bliską

Jak widać istnieje wiele więcej dzieje się w wywołaniu Rest/Ajax z punktu sieci widzenia, ponieważ dla każdego nowego połączenia należy ustanowić nowe połączenie, podczas gdy webSocket używa już otwartego połączenia. Ponadto w przypadkach webSocket serwer wysyła klientowi nowe dane, gdy są dostępne nowe dane - klient nie musi go regularnie żądać.

Jeśli informacje o cenach nie zmieniają się zbyt często, scenariusz REST/Ajax będzie również często wywoływał połączenia "bez wykonywania czynności", gdy klient żąda aktualizacji, ale nie ma nowych danych. Sprawa webSocket nigdy nie ma tej marnotrawnej sprawy, ponieważ serwer po prostu wysyła nowe dane, gdy są dostępne.

+0

Wielkie dzięki, to naprawdę pomaga! –

Powiązane problemy