Următorul este un rezumat al problemelor în implementarea unei componente socket de înaltă performanță; dacă trebuie să gestionezi doar mii de aplicații concurente, poți fi atent la scrierea codului, dar trebuie să te confrunți cu zeci de mii sau zeci de mii de aplicații simultane. Rezumatul următoarelor întrebări este considerat de mare ajutor pentru redactarea acestei cereri.
SocketAsyncEventArgs
Acest obiect este furnizat după .NET 2.0 sp1 și este folosit în principal pentru implementarea procesării de înaltă performanță a datelor de trimiterea și recepția de socket (pentru o introducere mai detaliată, puteți merge la MSDN). Acest obiect oferă trei moduri de a seta bufferele pentru trimiterea și recepția aferentelor: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, primele două nu pot coexista cu cele din urmă ( MSDN explică de ce). Când setezi un Buffer, fie că este SetBuffer(Byte(), Int32, Int32) sau BufferList, încearcă să-l setezi o singură dată pe fiecare instanță SocketAsyncEventArgs pe durata de viață a programului, deoarece această setare poate fi foarte consumatoare de resurse. Se recomandă setarea bufferului de date prin SetBuffer(Byte(), Int32, Int32) în timpul construcției SocketAsyncEventArgs, apoi utilizarea SetBuffer(Int32, Int32) pentru a gestiona acest lucru. Când doriți să setați un BufferList, este mai bine să nu schimbați <byte>sursa de octet[] la care IList <ArraySegment>face referire. Dacă se schimbă, SocketAsyncEventArgs va reasocia bufferul și va afecta eficiența.
Pool-ul SocketAsyncEventArgs
După cum s-a menționat mai sus, încercați să nu schimbați bufferul referențiat de SocketAsyncEventArgs cât mai mult posibil pentru a atinge acest scop. Prin urmare, este necesar să se construiască un pool de aplicații SocketAsyncEventArgs și să se inițializeze obiectul SocketAsyncEventArgs cât mai mult posibil la începutul programului. Pe lângă reducerea creării de SocketAsyncEventArgs, construirea pool-urilor poate economisi considerabil și memorie. Principalul motiv este că nu poți ști cât de mare este fiecare mesaj, desigur, poți da mesajului o limită maximă înainte de proiectare și apoi să setezi buffer-ul corespunzător SocketAsyncEventArgs. Totuși, aceasta este o mare pierdere de memorie, deoarece nu toate mesajele au o lungime maximă. Alocă o cantitate adecvată de dimensiune a bufferului către SocketAsyncEventArgs, oferă apeluri prin pool-uri și scrie flexibil mesaje către unul sau mai multe SocketAsyncEventArgs sau stochează mai multe mesaje într-un singur SocketAsyncEventArgs pentru procesare.
Coadă
Văd că multe practici sunt să deschizi firele direct sau să le arunci în pool-ul de fire după ce primești date, ceea ce este foarte rău pentru că nu controlează mai bine munca firelor, inclusiv așteptarea firelor. Cu fire personalizate + cozi, poți controla câte fire sunt responsabile pentru ce lucrare, iar lucrarea aflată la coadă va exista doar în coadă; Nu va exista un număr mare de fire de execuție sau un număr mare de linii în așteptare, ceea ce va determina sistemul de operare să piardă resurse din cauza programării firelor de execuție.
Consolidarea întârziată a datelor
Transmiterea întârziată a datelor prin fuziune este o metodă de a rezolva problema operațiunilor excesive de IO în rețea, care nu este folosită în multe scenarii, dar este comună pe serverele de jocuri. Cineva mi-a pus o întrebare înainte: dacă sunt 400 de utilizatori în scenă, schimbarea mediului fiecărui utilizator va informa ceilalți utilizatori. Dacă datele combinate nu sunt folosite, acestea vor produce o operațiune de IO de rețea foarte periculoasă, care este dificil de suportat pentru sistemul de numere de operațiuni IO. Prin urmare, este necesar să se fuzioneze și să se trimită datele într-un interval de întârziere adecvat pentru aplicația curentă. |
Postat pe 02.11.2016 09:53:37
|
|
|
