Følgende er en opsummering af problemerne ved at implementere en højtydende socket-komponent; hvis du kun skal håndtere tusindvis af samtidige applikationer, kan du være opmærksom på kodeskrivningen, men du skal håndtere titusindvis eller titusindvis af samtidige applikationer. Sammenfatningen af følgende spørgsmål menes at være til stor hjælp for udarbejdelsen af denne ansøgning.
SocketAsyncEventArgs
Dette objekt leveres efter .NET 2.0 sp1 og bruges hovedsageligt til at implementere højtydende socket data send- og modtagelsesbehandling (for en mere detaljeret introduktion kan du gå til MSDN). Dette objekt giver tre måder at indstille bufferne til afsendelse og modtagelse af relaterede sends: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, de to første kan ikke eksistere side om side med sidstnævnte ( MSDN forklarer hvorfor). Når du sætter en Buffer, uanset om det er SetBuffer(Byte(), Int32, Int32) eller BufferList, så prøv kun at sætte den én gang pr. SocketAsyncEventArgs-instans gennem hele programmets levetid, da denne indstilling kan være meget ressourcekrævende. Det anbefales at sætte databufferen gennem SetBuffer(Byte(), Int32, Int32) under opbygningen af SocketAsyncEventArgs og derefter bruge SetBuffer(Int32, Int32) til at håndtere det. Når du vil sætte en BufferList, er det bedst ikke at ændre <byte>den byte[]-kilde, som IList refererer til<ArraySegment>. Hvis den ændres, vil det få SocketAsyncEventArgs til at ombinde bufferen og påvirke effektiviteten.
SocketAsyncEventArgs pool
Som nævnt ovenfor, prøv at undgå at ændre bufferen, som SocketAsyncEventArgs refererer til, så meget som muligt for at opnå dette mål. Derfor er det nødvendigt at opbygge en SocketAsyncEventArgs-applikationspool og initialisere SocketAsyncEventArgs-objektet så meget som muligt i programmets begyndelse. Ud over at reducere oprettelsen af SocketAsyncEventArgs kan opbygning af pools også spare hukommelse betydeligt. Hovedårsagen er, at du ikke kan vide, hvor stor hver besked er, selvfølgelig kan du give beskeden en maksimal grænse før design, og så sætte bufferen svarende til SocketAsyncEventArgs. Dette er dog et stort spild af hukommelse, fordi ikke alle beskeder har en maksimal længde. Alloker en passende bufferstørrelse til SocketAsyncEventArgs, leverer kald gennem pools, og skriver fleksibelt beskeder til en eller flere SocketAsyncEventArgs, eller gemmer flere beskeder i én SocketAsyncEventArgs til behandling.
kø
Jeg kan se, at mange praksisser er at åbne tråde direkte eller kaste dem i trådpuljen efter at have modtaget data, hvilket er meget dårligt, fordi det ikke bedre styrer trådenes arbejde, inklusive ventetiden på tråde. Med brugerdefinerede tråde + køer kan du styre, hvor mange tråde der er ansvarlige for hvilket arbejde, og det køede arbejde vil kun eksistere i køen; Der vil ikke være et stort antal tråde eller et stort antal linjer, der venter, hvilket vil få operativsystemet til at miste ressourcer på grund af trådplanlægning.
Forsinket konsolidering af data
Forsinket dataoverførsel ved sammenfletning er en metode til at løse problemet med overdreven netværks-IO-operationer, som ikke bruges i mange scenarier, men er almindelig i spilservere. Nogen spurgte mig før: Hvis der er 400 brugere i scenen, vil hver brugers miljøændring fortælle de andre brugere. Hvis de samlede data ikke bruges, vil det skabe en meget frygtelig netværks-IO-operation, som er vanskelig for IO-operationsnummersystemet at bære. Derfor er det nødvendigt at sammenflette og sende data inden for et passende forsinkelsesinterval for den aktuelle applikation. |
Opslået på 02/11/2016 09.53.37
|
|
|
