Seuraavassa on yhteenveto suorituskykyisen socket-komponentin toteutuksen ongelmista: jos tarvitset vain tuhansia samanaikaisia sovelluksia, voit kiinnittää huomiota koodin kirjoittamiseen, mutta sinun täytyy kohdata kymmeniä tuhansia tai kymmeniä tuhansia samanaikaisia sovelluksia. Seuraavien kysymysten yhteenveto uskotaan olevan suureksi avuksi tämän hakemuksen kirjoittamisessa.
SocketAsyncEventArgs
Tämä objekti on saatavilla .NET 2.0 sp1:n jälkeen ja sitä käytetään pääasiassa suorituskykyisen socket-datan lähetys- ja vastaanottoprosessoinnin toteuttamiseen (yksityiskohtaisempaa esittelyä varten voit mennä MSDN:lle). Tämä olio tarjoaa kolme tapaa asettaa puskurit lähetyksiin ja vastaanottoon: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, ensimmäiset kaksi eivät voi toimia rinnakkain jälkimmäisten kanssa ( MSDN selittää miksi). Kun asetat puskurin, olipa se sitten SetBuffer(Byte(), Int32, Int32) tai BufferList, yritä asettaa se vain kerran per SocketAsyncEventArgs -instanssi ohjelman elinkaaren aikana, sillä tämä asetus voi olla hyvin resurssikuluttava. On suositeltavaa asettaa datapuskuri SetBuffer(Byte(), Int32, Int32) kautta SocketAsyncEventArgsin rakentamisen aikana, ja sen jälkeen käyttää SetBuffer(Int32, Int32) sen käsittelyyn. Kun haluat asettaa BufferListin, on parasta olla <byte>vaihtamatta IListin viitamaa tavua[] <ArraySegment>lähdekoodia. Jos sitä muutetaan, se saa SocketAsyncEventArgsin sitomaan puskurin uudelleen ja vaikuttamaan tehokkuuteen.
SocketAsyncEventArgs pool
Kuten yllä mainittiin, yritä olla muuttamatta SocketAsyncEventArgsin viittaamaa puskuria mahdollisimman paljon tämän tavoitteen saavuttamiseksi. Siksi on tarpeen rakentaa SocketAsyncEventArgs-sovelluspooli ja alustaa SocketAsyncEventArgs-objekti mahdollisimman paljon ohjelman alussa. SocketAsyncEventArgsin luomisen vähentämisen lisäksi poolien rakentaminen voi myös säästää huomattavasti muistia. Pääsyy on se, ettet voi tietää, kuinka suuri kukin viesti on, tietenkin voit antaa viestille maksimirajan ennen suunnittelua ja asettaa puskurin vastaamaan SocketAsyncEventArgsia. Tämä on kuitenkin suuri muistin hukka, koska kaikilla viesteillä ei ole maksimipituutta. Varaa sopiva määrä puskurikokoa SocketAsyncEventArgsille, tarjoa kutsuja poolien kautta ja kirjoita joustavasti viestejä yhdelle tai useammalle SocketAsyncEventArgsille tai tallentaa useita viestejä yhteen SocketAsyncEventArgs-järjestelmään käsittelyä varten.
jono
Näen, että monissa käytännöissä säikeiden avaaminen suoraan tai niiden heittäminen säikeiden pooliin datan vastaanottamisen jälkeen, mikä on todella huono asia, koska se ei hallitse säikeiden työtä paremmin, mukaan lukien säikeiden odotus. Mukautetuilla säikeillä + jonoilla voit hallita, kuinka monta säiettä on vastuussa mistä työstä, ja jonotettu työ on vain jonossa; Säikeitä ei ole suurta määrää tai paljon rivejä odottamassa, mikä aiheuttaa käyttöjärjestelmän resurssien menetyksen säikeiden ajoituksen vuoksi.
Viivästynyt datan yhdistäminen
Viivästetty yhdistämistiedonsiirto on keino ratkaista liiallinen verkon IO-toimintojen ongelma, jota ei monissa tilanteissa käytetä, mutta se on yleistä pelipalvelimilla. Joku kysyi minulta aiemmin, jos skenessä on 400 käyttäjää, jokaisen käyttäjän ympäristön muutos kertoo muille käyttäjille. Jos yhdistettyä dataa ei käytetä, syntyy erittäin pelottava verkon IO-toiminto, joka on IO-operaationumerojärjestelmälle vaikea kantaa. Siksi on tarpeen yhdistää ja lähettää data sopivan viivevälin sisällä nykyiselle sovellukselle. |
Julkaistu 2.11.2016 9.53.37
|
|
|
