2013-06-28 10 views
14

Buduję niezwykle wydajne oprogramowanie dla przedsiębiorstw, które będzie odbierać, obsługiwać i odpowiadać na ponad 50 000 żądań TCP na sekundę. Rozprzestrzenia się na kilku serwerach Amazon EC2, ale chciałbym uzyskać pojedynczy serwer, który byłby w stanie obsłużyć jak najwięcej tysięcy zgłoszeń na sekundę (fotografowanie za 5k/sek). Najprawdopodobniej zamierzam używać instancji m1.xlarge z Amazon Linuksem.Najbardziej wydajne wysokowydajne oprogramowanie do obsługi gniazdek/gwintów

Buduję to oprogramowanie w C++ z Boost ASIO i próbuję znaleźć najbardziej efektywny sposób projektowania architektury gniazda. W przykładach (http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/examples.html) jestem skłonny do emulacji "serwera HTTP 2", ponieważ będziemy mieli wiele vCPU dla pracownika.

Ktoś naprawdę mógłby opisać zalety/wady każdego z przykładów serwera HTTP i radzić sobie z tymi wieloma połączeniami. Byłbym wdzięczny za wszelkie dodatkowe informacje (dotyczące gniazd Boost i/lub wysokowydajnej konfiguracji EC2).

Dziękuję bardzo!

+2

Podczas gdy 50k wiadomości na sekundę nie jest dokładnie odsuwane, nie nazwałbym tego "wyjątkowo wysoką wydajnością". http://www.marketdatapeaks.com/ –

+0

Dla mnie jest wyjątkowo wydajny.Oczywiście nie jest to wielkość giełdowa (oczywiście jest wiele innych firm zajmujących się większymi wolumenami), ale każde z tych 50-krotnych żądań ma przyzwoitą ilość przetwarzania do wykonania na zapleczu (nie tylko w postaci plików statycznych), więc uważają, że jest dość intensywny. Czy masz jakieś doświadczenie z czymś takim? Dzięki! – Harry

+0

Mam, ale niestety nie mam żadnej wiedzy o przytoczonych przykładach. –

Odpowiedz

0

Możesz zajrzeć do gniazd niezablokowanych i rozdzielić wejście/wyjście/przetwarzanie na osobne wątki. Czy może utworzyć 3 nowe wątki wejścia/wyjścia/przetwarzania na tysiąc połączeń?

Nadzieję, że pomaga.

3

Kilka sugestii:

Nie wspomniałeś o tym, co robi twój serwer. Czy to będzie przyjmowanie i zamykanie 50K nowych żądań na sekundę, czy tylko obsługa wiadomości (żądań) z ustanowionych połączeń TCP. Więc moja rada może być trochę ogólna.

  1. Czytaj problem C10K: http://www.kegel.com/c10k.html

  2. Invest w użyciu epoll jako rozwiązanie powiadomień gniazdo zamiast ASIO. epoll nie jest trudny.

  3. Rozważ użycie ustalonej liczby wątków (2-8). Albo zrównoważyć obciążenie połączeń gniazda przez te wątki, albo po prostu użyć puli roboczej wątków do wiadomości żądania usługi przetworzonych z wątku gniazda. Projektuj wiele wątków, ale zacznij od użycia tylko jednego wątku. Następnie rozwiązuj wszystkie problemy z wydajnością. Po uzyskaniu dobrego działania rozwiązania z pojedynczym gwintem i maksymalnej wydajności należy rozważyć zwiększenie liczby wątków, tak aby można było przetwarzać wiele operacji, a inne wątki były blokowane.

  4. Istnieje duża szansa, że ​​problemy z wydajnością serwera będą wykraczały poza projekt gniazda. Ciągle testuj i uruchamiaj narzędzia, takie jak valgrind, aby zrozumieć, gdzie kod spędza większość swojego czasu. Szanse są wysokie, to tam, gdzie najmniej się tego spodziewasz. Na przykład na moim serwerze stwierdziłem, że większość czasu poświęcano na przydzielanie i zwalnianie pamięci dla buforów o niewielkiej temperaturze. Nigdy bym tego nie zgadł. Następnie zmieniłem projekt serwera, aby przydzielić pamięć z góry, używać pamięci stosu itp., Tak aby obsługa żądania nigdy nie wymagała kodu do alokacji pamięci. Wydajność z łatwością podwoiła się po wprowadzeniu tej zmiany.

+0

Zwiększenie asio powinno być przy użyciu epoll, zobacz http://stackoverflow.com/questions/3106304/boost-asio-on-linux-not-using-epoll – mark

+0

Według mojego wyboru na razie nie ma problemu z C10K, ten link też jest przereklamowany. Ostatnio przeniosłem nasz projekt z samodzielnie napisanego reaktora epilacyjnego do ASIO. Teraz może zarządzać 10 razy większą liczbą połączeń i nie opóźnia się w przypadku każdego klienta typu buggy; TLS działa również bardzo dobrze w opozycji do ręcznego korzystania z bibliotek; teraz wszystkie timery serwerów są asynchroniczne w przeciwieństwie do wersji epoll (która nie ma nic na temat timerów). Aplikacja asynchroniczna to nie tylko epoll; to timery, klienci buggy i wiele innych rzeczy, których nauczysz się tylko w produkcji – PSIAlt

Powiązane problemy