Az alábbiakban összefoglaljuk a nagy teljesítményű socket komponens megvalósításának problémáit: ha csak több ezer egyidejű alkalmazással kell foglalkoznod, akkor figyelhetsz a kódírásra, de több tízezer vagy tízezer párhuzamos alkalmazással kell szembenézned. Az alábbi kérdések összefoglalása nagy segítséget jelent a kérelem megírásában.
SocketAsyncEventArgs
Ez az objektum a .NET 2.0 sp1 után érhető el, és főként nagy teljesítményű socket adatküldési és fogadási feldolgozás megvalósítására szolgál (részletesebb bevezetésért az MSDN-en keresztül találhatsz). Ez az objektum háromféleképpen biztosít a kapcsolódó küldések küldésére és fogadására vonatkozó puffereket: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, az első kettő nem létezhet együtt az utóbbival ( MSDN elmagyarázza, miért). Amikor beállítasz egy puffert, legyen az SetBuffer(Byte(), Int32, Int32) vagy BufferList, próbáld meg csak egyszer beállítani SocketAsyncEventArgs instance-onként a program élete alatt, mert ez a beállítás nagyon erőforrásigényes lehet. Ajánlott, hogy a SocketAsyncEventArgs építése során a SetBuffer(Byte(), Int32, Int32) segítségével állítsuk be az adatpuffert, majd a SetBuffer(Int32, Int32) segítségével kezeljük. Amikor BufferListet akarsz beállítani, a legjobb, ha nem <byte>változtatod meg az IList által hivatkozott bájt[] <ArraySegment>forrást. Ha megváltoztatják, akkor a SocketAsyncEventArgs újraköti a puffert, ami befolyásolja a hatékonyságot.
SocketAsyncEventArgs pool
Ahogy fentebb említettük, próbáld meg nem változtatni a SocketAsyncEventArgs által hivatkozott puffert a lehető legtöbbet, hogy elérd ezt a célt. Ezért szükséges egy SocketAsyncEventArgs alkalmazáskészletet építeni, és a program elején a SocketAsyncEventArgs objektumot a lehető leginkább inicializálni. A SocketAsyncEventArgs létrehozásának csökkentése mellett a poolok építése jelentősen megtakaríthatja a memóriát is. A fő ok az, hogy nem tudhatod, mekkora az egyes üzenetek, természetesen adhatsz egy maximális határt az üzenetnek a tervezés előtt, majd beállíthatod a puffert a SocketAsyncEventArgs-nak. Ez azonban nagy memóriapazarlás, mert nem minden üzenetnek van maximális hossza. Megfelelő mennyiségű pufferméretet osztanak ki a SocketAsyncEventArgs-nak, hívjanak meg a poolokon keresztül, és rugalmasan írjanak üzeneteket egy vagy több SocketAsyncEventArgs-ba, vagy több üzenetet tároljanak egy SocketAsyncEventArgs-ban feldolgozásra.
Sor
Látom, hogy sok gyakorlat az, hogy közvetlenül nyitják a szálakat, vagy az adat kapása után a szál poolba dobják őket, ami nagyon rossz, mert nem szabályozza jobban a szálak munkáját, beleértve a szálak várakozását is. Egyedi szálak + sorok esetén szabályozhatod, hány szál felelős milyen munkáért, és a sorban lévő munka csak a sorban fog létezni; Nem lesz nagy szál vagy sok sor, ami miatt az operációs rendszer erőforrásvesztést okoz a száltervezés miatt.
Adatok késleltetett konszolidációja
A késleltetett összeolvasztott adatátvitel egy eszköz a túlzott hálózati IO műveletek problémájának megoldására, amelyet sok esetben nem használnak, de a játékszervereken gyakori. Valaki korábban feltett nekem egy kérdést: ha 400 felhasználó van a jelenetben, minden felhasználó környezetváltozása jelzi a többi felhasználónak. Ha az egyesített adatokat nem használják, nagyon félelmetes hálózati IO műveletet eredményez, ami nehéz a IO műveleti számrendszer számára. Ezért szükséges az adatokat megfelelő késleltetési intervallum között egyesíteni és küldeni a jelenlegi alkalmazáshoz. |
Közzétéve 2016. 11. 02. 9:53:37
|
|
|
