strzelanie do 2 tys endpointów

Odpowiedz Nowy wątek
2020-07-31 11:27

Rejestracja: 14 lat temu

Ostatnio: 5 godzin temu

0

Hej,

potrzebuję uderzać do ok 2000 endpointów. Każdy z nich zwraca te same dane, ok 30 wartości pewnych parametrów. Większość wartości parametrów chciałbym uzyskiwać co 30 max 60 sekund. Kilka z nich co 1sek. Taki kolektor danych z moich urządzeń.

  1. Zastanawiam się czy job ( @Schedule ) lub kilka jobów ( w zależności od interwału ) + @Async metoda uderzająca na poszczególne końcówki "odpowiednio" to dobry pomysł? Odpowiednio, mam na myśli jakiś thread pool - tutaj jeszcze dokładnie nie wiem co i jak ?

  2. Użycie Prometeusza (https://prometheus.io/), skonfigurowanie pliku konfiguracyjnego yml na 2000 endpointów i puszczenie bestii w ruch. Tutaj jednak chciałbym dane pchać dalej do np. postgresa.

proszę o Wasze przemyślenia w tym tasku, sugestie, etc...

edytowany 1x, ostatnio: john_doe, 2020-07-31 11:33

Pozostało 580 znaków

2020-07-31 11:48
Moderator

Rejestracja: 16 lat temu

Ostatnio: 2 godziny temu

0

Jak potrzebujesz te dane ciągle to może lepiej użyć jakiegoś socketa/websocketa zamiast RESTa?


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2020-07-31 11:56

Rejestracja: 14 lat temu

Ostatnio: 5 godzin temu

0

nie wiem jeszcze czy będę miał taką możliwość. Urządzenia są podpięte pod moduły internetowe ( jakieś, nie wiem na ten moment konkretów ).

Pozostało 580 znaków

2020-07-31 11:57

Rejestracja: 8 lat temu

Ostatnio: 4 godziny temu

4

Przetestuj. Zrób joba walnij reaktywnym web clientem w te 2000 endpointów i zobacz co się położy.
Jeżeli ty tworzesz urządzenia to pytanie czy lepiej nie byłoby odwrócić logiki aby to urządzenia wysyłały dane do serwera jak coś sie np zmieni.

Pozostało 580 znaków

2020-07-31 12:10

Rejestracja: 1 rok temu

Ostatnio: 10 minut temu

0
Schadoow napisał(a):

Jeżeli ty tworzesz urządzenia to pytanie czy lepiej nie byłoby odwrócić logiki aby to urządzenia wysyłały dane do serwera jak coś sie np zmieni.

Dokładnie tak, odpytywanie 2000 endopitów to będzie jakaś maskra - potrzebujesz 2000 wątków, bo jak ci jeden endpoit przytnie ta całość siądzie.
Dużo tez zależy jakie to dane. Co z nimi chcesz zrobić. Czy możesz je agregować, czy chcesz trzymać w wersji surowej.

edytowany 2x, ostatnio: Tomek Pycia, 2020-07-31 12:12
no bez przesady, mozna wziac jakis non-blocking klient http albo libke implementujaca cooperative multitasking i na 1 watku to ogarnac. Ofc zgadzam sie, ze model push jakby sie dalo tutaj zaimplementowac to bylby najlepszy - pedegie 2020-07-31 12:24

Pozostało 580 znaków

2020-07-31 12:18

Rejestracja: 12 lat temu

Ostatnio: 11 minut temu

0

Może najprościej jak się da - task scheduler. Lecisz sobie paczkami (np. 100 endpointow, których czas na odpytanie minął) i wykonujesz dla każdej paczki zrownoleglone requesty, wyniki zapisujesz, przesuwasz daty kolejnego odpytania lub tworzysz nowe taski. Alternatywnie zamiast paczek większa liczba workerów. W obu podejściach potrzebujesz zrobić sobie pulę wątków.

Do tego potrzebny mechanizm obsługi błędów (np. retry, cb) i jakieś limitowanie, żeby nie zabić tych urządzeń.


IT mikromenadżer
edytowany 2x, ostatnio: Charles_Ray, 2020-07-31 12:23

Pozostało 580 znaków

2020-07-31 12:21

Rejestracja: 14 lat temu

Ostatnio: 5 godzin temu

0

ja nie tworzę tych urządzeń.
dane potrzebuję surowo wrzucić do bazy z oznaczeniem skąd one pochodzą ( id urządzenia ) oraz opatrzyć je timestampem.
Będę rozmawiał z gościem co tworzy te urządzenia, jednak wiem, że on coś kręci nosem na takie podejście.

Nie dziwne - przerzucasz wtedy na niego obsługę błędów itd :) - Charles_Ray 2020-07-31 12:22
Postgres tego nie uniesie - 2000 edpoitów X 30 wartości X 60 secund X 60 minut - daje 216 milinów na godzine. Musisz użyć czegoś dedykowanego pod sekwencje czasowe. - Tomek Pycia 2020-07-31 12:26

Pozostało 580 znaków

2020-07-31 12:24

Rejestracja: 2 lata temu

Ostatnio: 10 godzin temu

0

a nie da sie zrobić jakiegoś agregatu, typu ze jedno urządzenie na danym obszarze to master ;) i odpytuje pozostałe i wysyła całość

Pozostało 580 znaków

2020-07-31 12:27

Rejestracja: 14 lat temu

Ostatnio: 5 godzin temu

0

dyskusja otwarta, jednak na ten moment najprawdopodobniej twórca tych urządzeń i sterownika, emitera, dorobi jakiś rest

Pozostało 580 znaków

2020-07-31 12:29

Rejestracja: 3 lata temu

Ostatnio: 2 godziny temu

Lokalizacja: 700m n.p.m.

0

Niekoniecznie potrzeba 2000 wątków, można mniej wątków i wtedy na jeden wątek przypada:

x = liczba endopointów / liczba wątków

Jeżeli jakiś endpoint przymuli to nie zablokuje wszystkiego tylko max x-1

edytowany 3x, ostatnio: TomRZ, 2020-07-31 12:36
Chyba odwrotnie ten ułamek ;) - Pinek 2020-07-31 12:36
Tak, poprawilem - TomRZ 2020-07-31 12:36

Pozostało 580 znaków

2020-07-31 13:03

Rejestracja: 7 lat temu

Ostatnio: 29 minut temu

0

pomijając temat wysyłania danych w odwrotna stronę albo socketów, jeśli musisz zostać przy pobieraniu ich z endpointów to może ci się przydać np. hystrix skoro korzystasz z spring boota, żeby nie zapchać wszystkich wątków i mieć jakiś mechanizm fault-tolerance

możesz też rozbić to na kilka instancji i każda będzie odpowiadać za jakąś część całej puli np 4x po 500 endpointów, które będą sobie pobierać endpointy z jakiegoś config serwera; co po części pozwoli uniknąć problemu z zapchaniem wszystkich wątków; ale najpierw odpalilbym chyba jakis test wydajnościowy żeby niepotrzebnie nie komplikować. a nuż jedna instancją z jakimś threadpoolem wystarczy

edytowany 1x, ostatnio: azalut, 2020-07-31 13:03
Hystrix jest deprecated - Charles_Ray 2020-07-31 15:08
hystrix nie jest aktywnie rozwijany tylko utrzymywany; to co innego niz deprecated ztcw :P - azalut 2020-08-01 11:41

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0