Poniżej znajduje się podsumowanie problemów związanych z implementacją komponentu gniazda o wysokiej wydajności; jeśli musisz radzić sobie tylko z tysiącami aplikacji równocześnie, możesz skupić się na pisaniu kodu, ale musisz zmierzyć się z dziesiątkami tysięcy lub dziesiątkami tysięcy aplikacji równocześnie. Podsumowanie poniższych pytań uważa się za bardzo pomocne w pisaniu tego wniosku.
SocketAsyncEventArgs
Obiekt ten jest udostępniany po .NET 2.0 sp1 i służy głównie do implementacji wysokowydajnego przetwarzania przesyłania i odbioru danych w gniazdach (dla bardziej szczegółowego wprowadzenia można przejść do MSDN). Obiekt ten oferuje trzy sposoby ustawiania do wysyłania i odbierania powiązanych wysyłań: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, z czego dwa pierwsze nie mogą współistnieć z tymi ostatnimi ( MSDN wyjaśnia dlaczego). Gdy ustawiasz Bufor, czy to SetBuffer(Byte(), Int32, Int32) czy BufferList, staraj się ustawić go tylko raz na każdą instancję SocketAsyncEventArgs przez cały okres życia programu, ponieważ takie ustawienie może być bardzo wymagające zasobów. Zaleca się ustawienie bufora danych przez SetBuffer(Byte(), Int32, Int32) podczas budowy SocketAsyncEventArgs, a następnie użycie SetBuffer(Int32, Int32) do jego obsługi. Gdy chcesz ustawić BufferList, najlepiej nie zmieniać <byte>źródła bajtu[], do którego odwołuje się IList<ArraySegment>. Jeśli zostanie zmieniony, spowoduje to ponowne powiązanie bufora przez SocketAsyncEventArgs i wpłynie na efektywność.
SocketAsyncEventArgs pool
Jak wspomniano powyżej, staraj się nie zmieniać bufora cytowanego przez SocketAsyncEventArgs tak często, jak to możliwe, aby osiągnąć ten cel. Dlatego konieczne jest zbudowanie puli aplikacji SocketAsyncEventArgs i inicjalizacja obiektu SocketAsyncEventArgs na początku programu, tak często, jak to możliwe. Oprócz ograniczenia tworzenia SocketAsyncEventArgs, budowa pul może również znacznie oszczędzać pamięć. Głównym powodem jest to, że nie możesz wiedzieć, jak duża jest każda wiadomość, oczywiście możesz podać jej maksymalny limit przed projektowaniem, a następnie ustawić bufor odpowiadający SocketAsyncEventArgs. Jednak to ogromna strata pamięci, ponieważ nie wszystkie wiadomości mają maksymalną długość. Przydziel odpowiednią ilość bufora do SocketAsyncEventArgs, dostarczaj wywołania przez pule i elastycznie zapisuj wiadomości do jednego lub więcej SocketAsyncEventArgs, albo przechowuj wiele wiadomości w jednym SocketAsyncEventArgs do przetwarzania.
kolejka
Widzę, że wiele praktyk polega na otwieraniu wątków bezpośrednio lub wrzucaniu ich do puli wątków po otrzymaniu danych, co jest bardzo złe, bo nie kontroluje lepiej pracy wątków, w tym oczekiwania wątków. Dzięki niestandardowym wątkom + kolejkom możesz kontrolować, ile wątków odpowiada za jaką pracę, a kolejkowa praca będzie istnieć tylko w kolejce; Nie będzie dużej liczby wątków ani linii oczekujących, co spowoduje utratę zasobów przez system operacyjny z powodu harmonogramowania wątków.
Opóźniona konsolidacja danych
Opóźniona transmisja danych scalanych to sposób na rozwiązanie problemu nadmiernej operacji IO sieci, który nie jest stosowany w wielu scenariuszach, ale jest powszechny na serwerach gier. Ktoś zadał mi kiedyś pytanie, jeśli w scenie jest 400 użytkowników, zmiana środowiska każdego użytkownika powie innym użytkownikom. Jeśli dane połączone nie zostaną wykorzystane, powstanie bardzo trudnej operacji sieciowej IO, co jest trudne do przesłów dla systemu numeracji operacji IO. Dlatego konieczne jest łączenie i przesyłanie danych w odpowiednich odstępach opóźnień dla bieżącej aplikacji. |
Opublikowano 02.11.2016 09:53:37
|
|
|
