Järgnevalt on kokkuvõte probleemidest kõrge jõudlusega sokli komponendi rakendamisel: kui pead tegelema vaid tuhandete samaaegsete rakendustega, siis võid keskenduda koodikirjutamisele, kuid pead arvestama kümnete tuhandete või kümnete tuhandete samaaegsete rakendustega. Arvatakse, et järgmiste küsimuste kokkuvõte on selle taotluse kirjutamisel suureks abiks.
SocketAsyncEventArgs
See objekt on saadaval pärast .NET 2.0 sp1 versiooni ja seda kasutatakse peamiselt kõrge jõudlusega sokli andmete saatmise ja vastuvõtmise töötlemiseks (täpsema sissejuhatuse leiate MSDN-ist). See objekt pakub kolme võimalust seotud saadete saatmise ja vastuvõtmise puhvrite määramiseks: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, esimesed kaks ei saa koos eksisteerida viimastega ( MSDN selgitab, miks). Kui seadistad puhvrit, olgu see siis SetBuffer(Byte(), Int32, Int32) või BufferList, proovi seda seadistada ainult üks kord iga SocketAsyncEventArgs eksemplari kohta kogu programmi eluea jooksul, sest see seade võib olla väga ressursimahukas. Soovitatav on seadistada andmepuhver SetBuffer(Byte(), Int32, Int32) kaudu SocketAsyncEventArgs ehitamisel ning seejärel kasutada SetBuffer(Int32, Int32) selle haldamiseks. Kui soovid seadistada BufferListi, on parem mitte muuta <byte>IListi viidatud bait[] <ArraySegment>allikat. Kui seda muuta, paneb see SocketAsyncEventArgs'i puhvri ümber siduma ja mõjutab efektiivsust.
SocketAsyncEventArgs pool
Nagu eespool mainitud, püüa mitte muuta SocketAsyncEventArgs'i viidatud puhvrit nii palju kui võimalik, et seda eesmärki saavutada. Seetõttu on vajalik luua SocketAsyncEventArgs rakenduste bassein ja initsialiseerida SocketAsyncEventArgs objekt võimalikult palju programmi alguses. Lisaks SocketAsyncEventArgs'i loomise vähendamisele võib basseinide konstrueerimine oluliselt säästa ka mälu. Peamine põhjus on see, et sa ei saa teada, kui suur iga sõnum on, muidugi võid enne disainimist anda sõnumile maksimaalse piiri ja seejärel määrata puhvri vastavalt SocketAsyncEventArgs-ile. See on aga suur mäluraiskamine, sest mitte kõik sõnumid ei ole maksimaalse pikkusega. Eralda sobiv hulk puhvri suurust SocketAsyncEventArgs-ile, esita kõnesid basseinide kaudu ning kirjuta paindlikult sõnumeid ühele või mitmele SocketAsyncEventArgs-ile või salvesta mitu sõnumit ühte SocketAsyncEventArgs-i töötlemiseks.
järjekord
Näen, et paljud praktikad on avada lõimed otse või visata need pärast andmete saamist lõimede pooli, mis on väga halb, sest see ei kontrolli paremini lõimede tööd, sealhulgas lõimede ootamist. Kohandatud lõimede + järjekordadega saad kontrollida, mitu lõime vastutab millegi töö eest, ja järjekorras olev töö eksisteerib ainult järjekorras; Ei ole suurt lõimede arvu ega ridu, mis ootavad, mis põhjustab operatsioonisüsteemi ressursside kaotuse lõimede ajastamise tõttu.
Andmete viivitusega konsolideerimine
Viivitusega ühendamise andmeedastus on vahend liigse võrgu IO operatsioonide probleemi lahendamiseks, mida paljudes olukordades ei kasutata, kuid mänguserverites on see tavaline. Keegi küsis minult varem, et kui stseenis on 400 kasutajat, siis iga kasutaja keskkonna muutus annab sellest teistele kasutajatele teada. Kui kombineeritud andmeid ei kasutata, tekib väga hirmutav võrgu IO operatsioon, mida IO operatsiooninumbrisüsteemil on raske kanda. Seetõttu on vajalik andmeid ühendada ja saata sobiva viivituse intervalli jooksul praeguse rakenduse jaoks. |
Postitatud 02.11.2016 09:53:37
|
|
|
