Jak wolne są gniazda TCP w porównaniu do nazwanych potoków w systemie Windows dla lokalnego hosta IPC?

Question

Pracuję nad serwerem proxy TCP, który zostanie umieszczony przed usługą TCP, która powinna obsłużyć od 500 do 1000 aktywnych połączeń z dzikiego Internetu.

Serwer proxy działa na tym samym komputerze co usługa i jest przeważnie przezroczysty. Usługa jest w większości nieświadoma istnienia serwera proxy, a jedynym wyjątkiem jest powiadomienie o rzeczywistym zdalnym adresie IP klientów.

Oznacza to, że dla każdego przychodzącego otwartego gniazda TCP są jeszcze dwa gniazda na serwerze: druga para w proxy, a druga w prawdziwej usłudze za serwerem proxy.

Rozmiary okien wysyłania i odzyskiwania dla dwóch gniazd proxy są ustawione na 1024 bajty.

Jakie są konsekwencje dla wydajności? Jak powolna jest ta konfiguracja? Czy powinienem starać się zmienić usługę, aby używała nazwanych potoków (lub innego mechanizmu IPC), czy gniazdo TCP lokalnego hosta jest w większości wydajnym IPC?

Połączenie dwóch aplikacji nie jest opcją. W tej chwili utknęliśmy w dwóch konfiguracjach procesu.

EDYCJA: Powodem posiadania dwóch oddzielnych procesów na tym samym sprzęcie jest ekonomia w 100%. Mamy tylko jeden serwer i nie planujemy więcej (bez pieniędzy).

Usługa TCP jest starszym oprogramowaniem w języku Visual Basic 6, które wykroczyło poza nasze oczekiwania. Proxy to C++. Nie mamy czasu, pieniędzy ani siły roboczej, aby przepisać i przenieść kod VB6 do nowoczesnego środowiska programistycznego.

Pośrednik to nasza próba złagodzenia konkretnego problemu z wydajnością usługi, którą otrzymujemy od czasu do czasu.

Pełnomocnikiem jest open source, and here is the project source code.

Answer 1

http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx

Pozwól Podsumowując dla ciebie. Jeśli martwisz się wydajnością, użyj protokołu TCP/IP. Ale jeśli masz naprawdę szybką sieć i nie martwisz się o wydajność, to Named Pipes będzie "schludny", ponieważ może zaoszczędzić ci trochę kodu.

Nie wspominając, jeśli pozostaniesz przy TCP, będziesz mieć coś, co można skalować, a nawet załadować zbalansowane, gdy nadejdzie czas.

Cheers,

Answer 2

Jaki jest powód, aby mieć pełnomocnictwa na tej samej maszynie, po prostu ciekawy?

Zresztą:

Istnieje kilka metod IPC, TCP/IP, nazwanych potoków są porównywalne pod względem szybkości i złożoności. Jeśli naprawdę chcesz czegoś, co dobrze się skaluje i prawie nie ma narzutów: korzystaj z pamięci współdzielonej. Najlepiej stosować w połączeniu z algorytmem blokującym dostęp do wskaźników (lub użyć jednego bufora dla każdego czytnika (proxy/usługa) i programu piszącego (usługa/proxy)).

Answer 3

W opisywanym scenariuszu lokalne połączenia TCP najprawdopodobniej nie będą wąskim gardłem. Oczywiście spowoduje to pewne obciążenie, ale powinno to być pomijalne, chyba że procesor jest już gorący.

Zakładając, że wykorzystanie procesora na serwerze zwykle wynosi mniej niż 50% (przy obecności proxy), nie warto martwić się o zminimalizowanie narzutu związanego z lokalnymi połączeniami TCP.

Jeśli użycie procesora jest regularnie wyższe niż 80%, prawdopodobnie powinieneś wykonać pewne profilowanie. Zacznę od porównania obciążenia procesora (lub, jeszcze lepiej, wydajności, jeśli można to zmierzyć w sposób znaczący), gdy serwer proxy jest na miejscu, kiedy nie jest. O ile serwer proxy nie wykonuje skomplikowanego przetwarzania, obciążenie związane z dodatkowymi połączeniami TCP jest prawdopodobnie znaczną częścią całkowitego obciążenia wprowadzonego przez serwer proxy, więc powinno to dać co najmniej oszacowanie rzędu wielkości, o ile " zyskać dzięki zastosowaniu bardziej wydajnej formy IPC.

Answer 4

Będzie to to samo (lub co najmniej nie mierzalnie różne). Winsock jest na tyle sprytny, aby wiedzieć, czy rozmawia z gniazdem na tym samym hoście, iw takim przypadku spowoduje zwarcie niemal wszystkiego poniżej IP i skopiuje dane bezpośrednio z bufora do bufora. Pod względem nazwanych potoków vs. gniazd, jeśli chcesz potencjalnie móc komunikować się z różnymi maszynami w przyszłości, wybierz gniazda. Jeśli wiesz, że nigdy nie będziesz tego potrzebował, wybierz tę, którą Twoi programiści znają najbardziej lub najwygodniej.

Answer 5

Dla każdego, kto przyjdzie, aby przeczytać to później, chcę dodać pewne ustalenia, które odpowiadają na oryginalne pytanie.

Dla rozwijającego się narzędzia mamy klasę sieci, która może używać nazwanych potoków lub TCP z tymi samymi połączeniami.

Oto typowy pętla z powrotem transfer plików w naszym systemie testowym: Czas transferu

TCP/IP: 2,5 sekundy
Named Pipes transferowe czasowe: 3.1 Sekund

Teraz, gdy idziesz na zewnątrz maszyny i połączyć się ze zdalnym komputerem w sieci wydajność dla nazwanych potoków jest znacznie gorzej:

TCP/IP czas transferu: 12 sekund
Named Pipes transferowe czas: 2,5 minuty (yes minut)

Zdaję sobie sprawę, że jest to tylko jeden system (Windows 7). Uważam jednak, że jest to dobry wskaźnik tego, jak wolno można używać nazwanych potoków ... i wygląda na to, że TCP jest drogą do zrobienia.