HttpWebRequest i porty do zakończenia operacji wejścia/wyjścia

Question

Pracuję nad aplikacją, która wymaga jednego typu wiadomości, aby trafić w bazę danych, i innego typu wiadomości, aby przejść do zewnętrznego api XML.

Muszę przetworzyć DUŻO ... jednym z największych wyzwań jest uzyskanie dobrej wydajności klasy HttpWebRequest. Początkowo zacząłem od używania standardowych metod synchronicznych i łączenia wątków. To nie było dobre.

Po pewnym lekturze przekonałem się, że zalecanym sposobem jest użycie metod Begin/End, aby przekazać pracę do portów zakończenia IO, co zwalnia pulę wątków i zapewnia lepszą wydajność. Wydaje się, że tak nie jest ... wydajność jest nieznacznie lepsza, ale z pewnością nie widzę zbyt dużych portów zakończenia operacji wejścia w porównaniu do wątków.

Mam wątek, który obraca się wokół i wysyła mi dostępne wątki robocze + porty zakończenia w wątku. Porty zakończeń są zawsze bardzo niskie (maks. Widziałem 9) i zawsze używam około 120 wątków roboczych (czasami więcej). Używam rozpoczęcia/zakończenia wzór dla wszystkich metod w httpwebrequest:

Begin/EndGetRequestStream 
Begin/EndWrite (Stream) 
Begin/EndGetResponse 
Begin/EndRead (Stream) 

robię to dobrze? Czy czegoś brakuje? Mogę używać (czasami) do 2048 połączeń http jednocześnie (z wyjścia netstat) - dlaczego numery portów zakończenia byłyby tak niskie?

Jeśli ktoś mógłby udzielić poważnej porady na temat tego, jak dobrze radzić sobie z tymi wątkami zarządzania, portami zakończenia i httpwebrequest, byłoby to niezwykle cenne!

EDIT: czy .NET jest rozsądnym narzędziem do tego? Czy mogę uzyskać dużą liczbę połączeń HTTP pracujących z .NET i stosem System.Net? Sugerowano użycie czegoś takiego jak WinHttp (lub jakiejś innej biblioteki C++) i wybranie go z .NET, ale nie jest to coś, co szczególnie chcę zrobić!

Answer 1

Sposób, w jaki to rozumiem, nie wiąże portu wszystkie czas, w którym żądanie asynchroniczne jest zaległe - jest tylko "zajęty", gdy dane zostały zwrócone i są przetwarzane w odpowiedni wątek. Mam nadzieję, że nie masz zbyt wiele pracy do wykonania w oddzwanianiu, dlatego nie masz wielu działających portów w tym samym czasie.

Czy jesteś teraz rzeczywiście jednak słaba wydajność? Czy powodem do niepokoju są tylko niskie liczby? Czy uzyskujesz przepustowość, jakiej oczekujesz?

Jednym z problemów, które możesz może mieć to, że pula połączeń HTTP dla jednego hosta jest stosunkowo niewielka. Jeśli masz setki próśb na tę samą maszynę, domyślnie tylko 2 żądania będą w danym momencie wykonywane na , aby uniknąć ataku DoS-a na hosta, o którym mowa (i uzyskać korzyści z utrzymywania przy życiu). Możesz zwiększyć to programowo lub używając app.config. Oczywiście może to nie być problemem w Twojej sprawie, ponieważ problem został już naprawiony lub wszystkie żądania dotyczą różnych hostów. (Jeśli netstat pokazuje 2048 połączeń, to nie brzmi to źle.)

Answer 2

Być może metody EndRead powinny zapisywać wyniki tylko w kolejce wątków bezpiecznych, które następnie odczytujesz z niewielkiej liczby wątków roboczych, które są pod Twoją kontrolą . I/lub wykorzystaj fakt, że HttpWebRequest zasygnalizuje obiekt, który można oczekiwać, po zakończeniu i zapisze własną logikę, aby czekać na wszystkie zaległe żądania z pojedynczej (lub małej liczby) wątków.

Answer 3

Posiadanie tylko 9 wątków portu zakończenia faktycznie oznacza, że ​​prawdopodobnie używasz ich poprawnie i sprawnie. Zakładam, że maszyna, na której pracujesz, ma 8 rdzeni lub 4 rdzenie hiperwątkowe, co oznacza, że ​​system operacyjny będzie próbował w dowolnym momencie do 8 aktywnych (nie śpiących/blokujących/oczekujących) wątków portów zakończenia.

Jeśli jeden z uruchomionych wątków staje się nieaktywny (sleep/block/wait) i istnieją dodatkowe elementy do przetworzenia, zostanie utworzony dodatkowy wątek, aby utrzymać aktywny licznik na pozycji 8. Jeśli widzisz 9 wątków, to oznacza, że ​​nie wprowadzasz praktycznie żadnych blokad w metodach na twoich wątkach portowania i faktycznie pracujesz z CPU.

Jeśli masz 8 wątków aktywnie wykonujących pracę związaną z CPU na 8 rdzeniach, dodanie kolejnych wątków spowolni działanie (przełączanie kontekstów między wątkami będzie zmarnowanym czasem).

Na co powinieneś zwrócić uwagę, to dlaczego masz 120 innych wątków i co one robią.