Følgende er en oppsummering av problemene ved å implementere en høyytelses socket-komponent; hvis du bare trenger å håndtere tusenvis av samtidige applikasjoner, kan du følge med på kodeskrivingen, men du må møte titusenvis eller titusenvis av samtidige applikasjoner. Oppsummeringen av følgende spørsmål anses å være til stor hjelp for skrivingen av denne søknaden.
SocketAsyncEventArgs
Dette objektet leveres etter .NET 2.0 sp1 og brukes hovedsakelig til å implementere høyytelses socket-datasending og mottaksbehandling (for en mer detaljert introduksjon kan du gå til MSDN). Dette objektet gir tre måter å sette buffere for sending og mottak av relaterte sendinger: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, de to første kan ikke sameksistere med sistnevnte ( MSDN forklarer hvorfor). Når du setter en buffer, enten det er SetBuffer(Byte(), Int32, Int32) eller BufferList, prøv å sette den kun én gang per SocketAsyncEventArgs-instans gjennom programmets levetid, da denne innstillingen kan være svært ressurskrevende. Det anbefales å sette databufferen gjennom SetBuffer(Byte(), Int32, Int32) under konstruksjonen av SocketAsyncEventArgs, og deretter bruke SetBuffer(Int32, Int32) for å håndtere det. Når du vil sette en BufferList, er det best å ikke endre <byte>byte[]-kilden som IList refererer til<ArraySegment>. Hvis den endres, vil det føre til at SocketAsyncEventArgs binder bufferen på nytt og påvirker effektiviteten.
SocketAsyncEventArgs-pool
Som nevnt ovenfor, prøv å unngå å endre bufferen som refereres til av SocketAsyncEventArgs så mye som mulig, for å oppnå dette målet. Derfor er det nødvendig å bygge en SocketAsyncEventArgs-applikasjonspool og initialisere SocketAsyncEventArgs-objektet så mye som mulig i starten av programmet. I tillegg til å redusere opprettelsen av SocketAsyncEventArgs, kan bygging av pools også spare minne betydelig. Hovedgrunnen er at du ikke kan vite hvor stor hver melding er, selvfølgelig kan du gi meldingen en maksimal grense før design, og deretter sette bufferen tilsvarende SocketAsyncEventArgs. Dette er imidlertid et stort sløseri med minne, fordi ikke alle meldinger har en maksimal lengde. Alloker en passende bufferstørrelse til SocketAsyncEventArgs, tilby kall gjennom pooler, og skriv fleksibelt meldinger til én eller flere SocketAsyncEventArgs, eller lagre flere meldinger i én SocketAsyncEventArgs for behandling.
kø
Jeg ser at mange praksiser er å åpne tråder direkte eller kaste dem i trådpoolen etter å ha mottatt data, noe som er veldig dårlig fordi det ikke bedre kontrollerer arbeidet til tråder, inkludert ventingen på tråder. Med egendefinerte tråder + køer kan du kontrollere hvor mange tråder som er ansvarlige for hva som fungerer, og det køede arbeidet vil kun eksistere i køen; Det vil ikke være mange tråder eller mange linjer som venter, noe som vil føre til at operativsystemet mister ressurser på grunn av trådplanlegging.
Forsinket konsolidering av data
Forsinket overføring av sammenslåingsdata er en metode for å løse problemet med overdreven nettverks-IO-operasjoner, som ikke brukes i mange scenarioer, men som er vanlig på spillservere. Noen spurte meg et spørsmål før: Hvis det er 400 brukere i scenen, vil hver brukers miljøendring fortelle de andre brukerne. Hvis de kombinerte dataene ikke brukes, vil det føre til en svært fryktsom nettverks-IO-operasjon, noe som er vanskelig for IO-operasjonsnummersystemet å bære. Derfor er det nødvendig å slå sammen og sende data innenfor et passende forsinkelsesintervall for den nåværende applikasjonen. |
Publisert på 02.11.2016 09:53:37
|
|
|
