Toliau pateikiama didelio našumo lizdo komponento diegimo problemų santrauka, jei jums reikia dirbti tik su tūkstančiais vienu metu veikiančių programų, tuomet galite atkreipti dėmesį į kodo rašymą, tačiau turite susidurti su dešimtimis tūkstančių ar dešimtimis tūkstančių vienu metu veikiančių programų. Manoma, kad šių klausimų santrauka labai padės rašyti šią paraišką.
SocketAsyncEventArgs
Šis objektas pateikiamas po .NET 2.0 sp1 ir daugiausia naudojamas didelio našumo lizdo duomenų siuntimo ir gavimo apdorojimui įgyvendinti (išsamesniam įvadui galite eiti į MSDN). Šis objektas pateikia tris būdus, kaip nustatyti susijusių siuntimų siuntimo ir gavimo buferius: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, pirmieji du negali egzistuoti kartu su pastaruoju ( MSDN paaiškina, kodėl). Kai nustatote buferį, nesvarbu, ar tai būtų SetBuffer(Byte(), Int32, Int32) ar BufferList, pabandykite jį nustatyti tik vieną kartą kiekvienam SocketAsyncEventArgs egzemplioriui per visą programos gyvavimo laiką, nes šis parametras gali būti labai daug išteklių. Kuriant SocketAsyncEventArgs, rekomenduojama nustatyti duomenų buferį per SetBuffer(Byte(), Int32, Int32), o tada naudoti SetBuffer(Int32, Int32). Kai norite nustatyti BufferList, geriausia nekeisti <byte>IList nurodyto baito[] šaltinio<ArraySegment>. Jei jis bus pakeistas, "SocketAsyncEventArgs" iš naujo susieis buferį ir turės įtakos efektyvumui.
SocketAsyncEventArgs telkinys
Kaip minėta aukščiau, stenkitės kiek įmanoma nekeisti "SocketAsyncEventArgs" nurodyto buferio, kad pasiektumėte šį tikslą. Todėl programos pradžioje būtina sukurti "SocketAsyncEventArgs" programų telkinį ir kiek įmanoma inicijuoti "SocketAsyncEventArgs" objektą. Be to, kad sumažėja "SocketAsyncEventArgs" kūrimas, baseinų kūrimas taip pat gali labai sutaupyti atminties. Pagrindinė priežastis yra ta, kad jūs negalite žinoti, kokio dydžio kiekvienas pranešimas yra, žinoma, galite suteikti pranešimą maksimalią ribą prieš projektavimą, ir tada nustatyti buferį, atitinkantį SocketAsyncEventArgs. Tačiau tai yra didelis atminties švaistymas, nes ne visi pranešimai turi maksimalų ilgį. Paskirstykite atitinkamą buferio dydį SocketAsyncEventArgs, teikite skambučius per telkinius ir lanksčiai rašykite pranešimus į vieną ar daugiau SocketAsyncEventArgs arba saugokite kelis pranešimus viename SocketAsyncEventArgs apdorojimui.
eilė
Matau, kad daugelis praktikų yra tiesiogiai atidaryti gijas arba mesti jas į gijų fondą gavus duomenis, o tai yra labai blogai, nes geriau nekontroliuoja gijų darbo, įskaitant gijų laukimą. Naudodami pasirinktines gijas + eiles galite kontroliuoti, kiek gijų yra atsakingos už kokį darbą, o eilėje esantis darbas egzistuos tik eilėje; Nebus daug gijų ar daug eilučių, todėl operacinė sistema praras išteklius dėl gijų planavimo.
Uždelstas duomenų konsolidavimas
Uždelstas sujungimo duomenų perdavimas yra priemonė išspręsti pernelyg didelių tinklo IO operacijų problemą, kuri nėra naudojama daugelyje scenarijų, tačiau ji yra įprasta žaidimų serveriuose. Kažkas uždavė man klausimą anksčiau, jei yra 400 vartotojų scenoje, kiekvieno vartotojo aplinkos pokytis pasakys kitiems vartotojams. Jei sujungti duomenys nebus naudojami, tai sukels labai baisią tinklo IO operaciją, kurią sunku atlikti IO operacijų numerių sistemai. Todėl būtina sujungti ir išsiųsti duomenis per atitinkamą dabartinės programos delsos intervalą. |
Paskelbta 2016-11-02 09:53:37
|
|
|
