Nasleduje zhrnutie problémov pri implementácii vysokovýkonného komponentu socketu: ak potrebujete pracovať len s tisíckami súbežných aplikácií, môžete sa sústrediť na písanie kódu, ale musíte čeliť desaťtisícom alebo desaťtisícom súbežných aplikácií. Zhrnutie nasledujúcich otázok sa považuje za veľkú pomoc pri písaní tejto žiadosti.
SocketAsyncEventArgs
Tento objekt je poskytovaný po .NET 2.0 sp1 a používa sa hlavne na implementáciu vysokovýkonného spracovania odosielania a prijímania dát cez socket (pre podrobnejší úvod môžete ísť na MSDN). Tento objekt poskytuje tri spôsoby nastavenia bufferov pre odosielanie a prijímanie súvisiacich odosielaní: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, pričom prvé dva nemôžu existovať súčasne s posledným ( MSDN vysvetľuje prečo). Keď nastavujete Buffer, či už je to SetBuffer(Byte(), Int32, Int32) alebo BufferList, snažte sa nastaviť ho len raz na inštanciu SocketAsyncEventArgs počas celej životnosti programu, pretože toto nastavenie môže byť veľmi náročné na zdroje. Odporúča sa nastaviť dátový buffer cez SetBuffer(Byte(), Int32, Int32) počas konštrukcie SocketAsyncEventArgs a potom použiť SetBuffer(Int32, Int32) na jeho spracovanie. Keď chcete nastaviť BufferList, je najlepšie nemeniť <byte>zdroj bajtu[], na ktorý odkazuje IList<ArraySegment>. Ak sa to zmení, spôsobí to, že SocketAsyncEventArgs znovu naviaže buffer a ovplyvní efektivitu.
SocketAsyncEventArgs pool
Ako bolo spomenuté vyššie, snažte sa čo najviac meniť buffer, na ktorý odkazuje SocketAsyncEventArgs, aby ste dosiahli tento cieľ. Preto je potrebné vytvoriť aplikačný pool SocketAsyncEventArgs a inicializovať objekt SocketAsyncEventArgs čo najviac na začiatku programu. Okrem zníženia tvorby SocketAsyncEventArgs môže konštrukcia poolov výrazne šetriť pamäť. Hlavným dôvodom je, že nemôžete vedieť, aká veľká je každá správa, samozrejme môžete správe pred návrhom nastaviť maximálny limit a potom nastaviť buffer zodpovedajúci SocketAsyncEventArgs. Je to však veľká strata pamäte, pretože nie všetky správy majú maximálnu dĺžku. Prideliť primerané množstvo veľkosti bufferu do SocketAsyncEventArgs, poskytovať volania cez pooly a flexibilne zapisovať správy do jedného alebo viacerých SocketAsyncEventArgs, alebo ukladať viacero správ do jedného SocketAsyncEventArgs na spracovanie.
Queue
Vidím, že mnohé praktiky spočívajú v tom, že sa vlákna otvárajú priamo alebo sa po prijatí dát hodia do poolu vlákien, čo je veľmi zlé, pretože to lepšie neriadi prácu vlákien, vrátane čakania vlákien. S vlastnými vláknami + frontami môžete ovládať, koľko vlákien je zodpovedných za akú prácu, a zaradená práca bude existovať len v danej fronte; Nebude veľa vlákien ani veľa riadkov čakať, čo spôsobí stratu zdrojov v dôsledku plánovania vlákien.
Oneskorená konsolidácia dát
Oneskorený prenos dát pri zlúčení je spôsob, ako vyriešiť problém nadmerných sieťových IO operácií, ktorý sa v mnohých situáciách nepoužíva, ale je bežný na herných serveroch. Niekto sa ma už pýtal, ak je v scéne 400 používateľov, zmena prostredia každého používateľa to povie ostatným. Ak sa kombinované dáta nevyužijú, vznikne veľmi náročná sieťová IO operácia, ktorú je pre IO systém číslovania operácií ťažko prenášateľný. Preto je potrebné zlúčiť a odoslať dáta v primeranom oneskorenom intervale pre aktuálnu aplikáciu. |
Zverejnené 2. 11. 2016 9:53:37
|
|
|
