Wszystko, co czytałem o gniazdach w .NET, mówi, że asynchroniczny wzorzec zapewnia lepszą wydajność (szczególnie w przypadku nowej SocketAsyncEventArgs, która zapisuje przydział).Synchronizuj vs. Async Sockets Performance w .NET
Myślę, że ma to sens, jeśli mówimy o serwerze z wieloma połączeniami klientów, gdzie nie można przydzielić jednego wątku dla jednego połączenia. Wtedy widzę zaletę używania wątków ThreadPool i otrzymywania asynchronicznych wywołań zwrotnych na nich.
Ale w mojej aplikacji jestem klientem i muszę tylko wysłuchać jednego serwera wysyłającego dane rynkowe za pośrednictwem jednego połączenia tcp. W tej chwili tworzę pojedynczy wątek, nadaję najwyższy priorytet i wywołuję z nim Socket.Receive(). Moja nić blokuje to połączenie i budzi się, gdy nadejdą nowe dane.
Gdybym przełączyć to na wzór asynchroniczny, tak aby uzyskać wywołania zwrotnego, gdy pojawia się nowe dane, widzę dwie kwestie
wątków puli wątków będzie mieć domyślny priorytet więc wydaje się będą ściśle gorszy niż mój własny wątek, który ma najwyższy priorytet.
Nadal będę musiał wysłać wszystko przez jeden wątek w pewnym momencie. Załóżmy, że otrzymuję N callbacków prawie w tym samym czasie na N różnych wątkach wątku, powiadamiając mnie, że są nowe dane. Nioskowane przez nią tablice N nie mogą być przetwarzane w wątkach wątków, ponieważ nie ma gwarancji, że reprezentują N unikatowych komunikatów danych rynkowych, ponieważ TCP jest oparty na strumieniu. Będę musiał zablokować i umieścić bajty w tablicy i sygnalizować inny wątek, który może przetworzyć to, co jest w tablicy. Nie jestem więc pewien, co mnie kupiło N wątków z wątków.
Czy myślę o tym źle? Czy jest jakiś powód używania Async w moim konkretnym przypadku jednego klienta podłączonego do jednego serwera?
UPDATE:
Więc myślę, że było błędnie rozumiejąc wzór asynchronicznej w (2) powyżej. Otrzymałbym wywołanie zwrotne w jednym wątku roboczym, gdy były dostępne dane. Wtedy zacznę inny async odbierać i uzyskać inny oddzwanianie, itp. Nie dostanę N zwrotów w tym samym czasie.
Pytanie pozostaje jednak takie samo. Czy jest jakiś powód, że callbacks byłyby lepsze w mojej konkretnej sytuacji, w której jestem klientem i tylko podłączony do jednego serwera.
Dzięki za odpowiedź. Masz rację, patrzyłem na ten przykład źle. Dlatego zaczynam i odbieram wywołanie zwrotne w wątku threadpool, gdy są dane. Przetwarzam go i mogę zdecydować, że chcę dalej słuchać więcej i uzyskać kolejne wywołanie zwrotne. Ale nawet jeśli tak jest, nie widzę, jak to może być szybsze niż posiadanie jednego wątku o wysokim priorytecie poświęconego wykonywaniu funkcji Receive(). –
Po pierwsze, powinienem unikać ustawiania priorytetu wątków. Jestem prawie pewien, że generalnie nie jest to zalecane. Lepiej pozwolić wszystkim wątkom, które mają pracę do wykonania, uzyskać równy dostęp do procesora. Po drugie, moim celem jest to, że * nie * będzie szybsze. Wartość asynchronicznych API polega na tym, że pozwalają uniknąć wiązania wątku (kosztowny zasób ze względu na rozmiar stosu wywołań) w czystym czekaniu, a jeśli masz tylko jedno połączenie i jeden wątek i nic nie możesz zrobić, dopóki odzyskać dane, wtedy naprawdę nie ma wielkich kosztów związanych z zawiązaniem jednego wątku. Wyjątkiem jest użycie Silverlight, ponieważ ma tylko asynchroniczne. –
"Faster" jest prawie całkowicie dyskusyjny w tym scenariuszu, ponieważ tego rodzaju wybory zostaną utracone w hałasie w porównaniu do kosztu samej komunikacji sieciowej.Dosłownie nic nie zyskuje na wydajności, przełączając się między tymi technikami. –