Tālāk ir sniegts kopsavilkums par problēmām, kas saistītas ar augstas veiktspējas ligzdas komponenta ieviešanu, ja jums ir jārisina tikai tūkstošiem vienlaicīgu lietojumprogrammu, tad varat pievērst uzmanību koda rakstīšanai, bet jums ir jāsaskaras ar desmitiem tūkstošu vai desmitiem tūkstošu vienlaicīgu lietojumprogrammu. Tiek uzskatīts, ka šādu jautājumu kopsavilkums ir ļoti noderīgs šī pieteikuma rakstīšanai.
SocketAsyncEventArgs
Šis objekts tiek nodrošināts pēc .NET 2.0 sp1 un galvenokārt tiek izmantots, lai īstenotu augstas veiktspējas ligzdu datu sūtīšanas un saņemšanas apstrādi (detalizētāku ievadu varat doties uz MSDN). Šis objekts nodrošina trīs veidus, kā iestatīt buferus saistīto sūtījumu sūtīšanai un saņemšanai, SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, pirmie divi nevar pastāvēt kopā ar pēdējo ( MSDN paskaidro, kāpēc). Iestatot buferi, neatkarīgi no tā, vai tas ir SetBuffer(Byte(), Int32, Int32) vai BufferList, mēģiniet to iestatīt tikai vienu reizi katrā SocketAsyncEventArgs instancē visā programmas kalpošanas laikā, jo šis iestatījums var būt ļoti resursietilpīgs. SocketAsyncEventArgs izveides laikā ieteicams iestatīt datu buferi, izmantojot SetBuffer(Byte(), Int32, Int32), un pēc tam izmantot SetBuffer(Int32, Int32), lai to apstrādātu. Ja vēlaties iestatīt BufferList, vislabāk nav mainīt <byte>baitu[] avotu, uz kuru atsaucas IList<ArraySegment>. Ja tas tiek mainīts, tas izraisīs SocketAsyncEventArgs bufera atkārtotu piesaisti un ietekmēs efektivitāti.
SocketAsyncEventArgs baseins
Kā minēts iepriekš, mēģiniet pēc iespējas vairāk nemainīt buferi, uz kuru atsaucas SocketAsyncEventArgs, lai sasniegtu šo mērķi. Tāpēc ir nepieciešams izveidot SocketAsyncEventArgs lietojumprogrammu baseinu un pēc iespējas vairāk inicializēt SocketAsyncEventArgs objektu programmas sākumā. Papildus SocketAsyncEventArgs izveides samazināšanai, baseinu izveide var arī ievērojami ietaupīt atmiņu. Galvenais iemesls ir tas, ka jūs nevarat zināt, cik liels ir katrs ziņojums, protams, pirms projektēšanas varat piešķirt ziņojumam maksimālo ierobežojumu un pēc tam iestatīt buferi, kas atbilst SocketAsyncEventArgs. Tomēr tas ir liels atmiņas izšķiešana, jo ne visiem ziņojumiem ir maksimālais garums. Piešķiriet atbilstošu bufera lielumu SocketAsyncEventArgs, nodrošiniet zvanus, izmantojot pūlus, un elastīgi rakstiet ziņojumus uz vienu vai vairākiem SocketAsyncEventArgs vai glabājiet vairākus ziņojumus vienā SocketAsyncEventArgs apstrādei.
rinda
Es redzu, ka daudzas prakses ir tieši atvērt pavedienus vai mest tos pavedienu baseinā pēc datu saņemšanas, kas ir ļoti slikti, jo tas labāk nekontrolē pavedienu darbu, ieskaitot pavedienu gaidīšanu. Izmantojot pielāgotus pavedienus + rindas, jūs varat kontrolēt, cik pavedienu ir atbildīgi par kādu darbu, un rindā esošais darbs pastāvēs tikai rindā; Nebūs daudz pavedienu vai lielu rindu skaitu, kas gaida, kā rezultātā operētājsistēma zaudēs resursus pavedienu plānošanas dēļ.
Aizkavēta datu konsolidācija
Aizkavēta sapludināšanas datu pārraide ir līdzeklis, lai atrisinātu pārmērīgu tīkla IO operāciju problēmu, kas netiek izmantota daudzos scenārijos, bet tā ir izplatīta spēļu serveros. Kāds man uzdeva jautājumu iepriekš, ja ainā ir 400 lietotāji, katra lietotāja vides izmaiņas pateiks pārējiem lietotājiem. Ja apvienotie dati netiek izmantoti, tas radīs ļoti bailīgu tīkla IO darbību, ko IO operācijas numuru sistēmai ir grūti veikt. Tāpēc ir nepieciešams apvienot un nosūtīt datus atbilstošā aizkavēšanās intervālā pašreizējai lietojumprogrammai. |
Publicēts 02.11.2016 09:53:37
|
|
|
