2016-03-19 28 views
8

Używamy selera do generowania połączeń http od strony trzeciej. Mamy około 100 zadań, które po prostu wywołują zewnętrzne wywołania API HTTP. Niektóre zadania wywołują masowo interfejs API, na przykład pół miliona żądań o godzinie 4 rano rano, podczas gdy inne są ciągłym strumieniem wywołań API otrzymujących żądania prawie raz lub dwa razy na sekundę.Optymalizacja selera do zewnętrznych połączeń HTTP

Większość czasu reakcji interfejsu API wynosi od 500 do 800 ms.

Obserwujemy bardzo powolne tempo dostawy selera. W przypadku większości z powyższych zadań maksymalna szybkość dostarczania wynosi około 100/s (maks.) Do prawie 1/s (min). Uważam, że jest to bardzo słabe i coś jest zdecydowanie złe, ale nie jestem w stanie dowiedzieć się, co to jest.

Zaczynaliśmy od skupienia 3 serwerów i stopniowo tworzyliśmy klaster 7 serwerów, ale bez poprawy. Próbowaliśmy różnych ustawień współbieżności od autoskalowania do ustalonych 10, 20, 50, 100 pracowników. Nie ma backend wyniku, a naszym brokerem jest RabbitMQ.

Ponieważ nasz czas wykonywania zadań jest bardzo mały, mniej niż sekunda dla większości, staraliśmy się również, aby licznik prefetch był nieograniczony do różnych wartości.

--time-limit=1800 --maxtasksperchild=1000 -Ofair -c 64 --config=celeryconfig_production

Serwery 64 g RAM Centosu 6.6.

Czy możesz mi powiedzieć, co może być nie tak, lub wskazówki, jak go rozwiązać?

Czy powinniśmy iść z geodetami? Chociaż nie mam pojęcia, co to jest.

+0

Jak wypełniasz swoje kolejki w RabbitMQ? RabbitMQ jest najszybszy, gdy kolejki są puste. Możesz monitorować wykorzystanie procesora komputera RabbitMQ. Jeśli widzisz duże obciążenie procesora, prawdopodobnie dzieje się tak dlatego, że RabbitMQ dużo robi, aby poradzić sobie z ogromnym rozmiarem kolejki. – LearnerEarner

+1

Może brzmieć głupio i na pewno zwróciłeś na to uwagę, ale czy sprawdziłeś, czy serwer strony trzeciej zachowuje się dobrze pod obciążeniem? Czy nadal odpowiada na 500-800 ms, nawet jeśli trafisz na niego z wieloma równoległymi żądaniami? – LearnerEarner

+0

http://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/ – LearnerEarner

Odpowiedz

5

Po pierwsze - GIL - tak nie powinno być, ponieważ więcej maszyn powinno działać szybciej. Ale - proszę sprawdzić, czy obciążenie idzie tylko na jeden rdzeń serwera ...

Nie jestem pewien, czy w twoim przypadku dobry jest Celer. To świetne oprogramowanie z dużą funkcjonalnością. Ale jeśli to nie jest potrzebne, lepiej użyć czegoś prostszego - na wypadek gdyby niektóre z tych funkcji przeszkadzały. Chciałbym napisać mały PoC, sprawdzić inne oprogramowanie klienta, takie jak pika. Jeśli to nie pomoże - problem dotyczy infrastruktury. Jeśli pomaga - masz rozwiązanie. :)

Trudno powiedzieć, co się dzieje. Może to być coś z IO lub zbyt wieloma połączeniami sieciowymi ... Chciałbym się cofnąć - aby dowiedzieć się, co działa. Napisz testy integracyjne, ale upewnij się, że używasz 2-3 maszyn tylko po to, by użyć pełnego stosu tcp. Pamiętaj, aby mieć CI i uruchamiać te testy raz dziennie, lub tak - aby sprawdzić, czy wszystko idzie w dobrym kierunku.

+0

Również w niektórych szczególnych przypadkach GIL nie zwalnia po 100 ms –