Následuje shrnutí problémů při implementaci vysoce výkonné komponenty socketu: pokud potřebujete pracovat jen s tisíci současných aplikací, můžete se zaměřit na psaní kódu, ale musíte čelit desítkám tisíc nebo desítkám tisíc současných aplikací. Shrnutí následujících otázek je považováno za velkou pomoc při psaní této žádosti.
SocketAsyncEventArgs
Tento objekt je poskytován po .NET 2.0 sp1 a používá se především k implementaci vysoce výkonného zpracování odesílání a přijímání dat v socketu (pro podrobnější úvod můžete navštívit MSDN). Tento objekt nabízí tři způsoby nastavení bufferů pro odesílání a příjem souvisejících sendů: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, přičemž první dva nemohou koexistovat s posledními ( MSDN vysvětluje proč). Když nastavujete Buffer, ať už je to SetBuffer(Byte(), Int32, Int32) nebo BufferList, snažte se nastavit ho pouze jednou na instanci SocketAsyncEventArgs během celé životnosti programu, protože toto nastavení může být velmi náročné na zdroje. Doporučuje se nastavit datový buffer pomocí SetBuffer(Byte(), Int32, Int32) během konstrukce SocketAsyncEventArgs a poté použít SetBuffer(Int32, Int32) k jeho zpracování. Když chcete nastavit BufferList, je nejlepší neměnit <byte>zdroj bajtu[], na který se odkazuje IList<ArraySegment>. Pokud se změní, způsobí to, že SocketAsyncEventArgs převáže buffer a ovlivní efektivitu.
SocketAsyncEventArgs pool
Jak bylo zmíněno výše, snažte se co nejméně měnit buffer, na který odkazuje SocketAsyncEventArgs, abyste tohoto cíle dosáhli. Proto je nutné vytvořit aplikační pool SocketAsyncEventArgs a inicializovat objekt SocketAsyncEventArgs co nejvíce na začátku programu. Kromě omezení vzniku SocketAsyncEventArgs může konstrukce poolů také výrazně šetřit paměť. Hlavním důvodem je, že nemůžete vědět, jak velká je každá zpráva, samozřejmě můžete dát zprávě maximální limit před návrhem a pak nastavit buffer odpovídající SocketAsyncEventArgs. To je však velká ztráta paměti, protože ne všechny zprávy mají maximální délku. Přidělte vhodné množství bufferu do SocketAsyncEventArgs, poskytujte volání přes pooly a flexibilně zapisujte zprávy do jednoho nebo více SocketAsyncEventArgs, nebo ukládejte více zpráv do jednoho SocketAsyncEventArgs pro zpracování.
fronta
Vidím, že mnoho praktik spočívá v tom, že se vlákna otevírají přímo nebo se po přijetí dat vracejí do poolu, což je velmi špatné, protože to lépe neřídí práci vláken včetně čekání na vlákna. S vlastními vlákny + frontami můžete ovládat, kolik vláken je zodpovědných za jakou práci, a práce ve frontě bude existovat pouze ve frontě; Nebude zde velký počet vláken ani čekací řádků, což způsobí, že operační systém ztratí zdroje kvůli plánování vláken.
Zpožděná konsolidace dat
Zpožděný přenos dat při sloučení je způsob, jak řešit problém nadměrných provozů síťových IO, který se v mnoha případech nepoužívá, ale je běžný na herních serverech. Někdo se mě už jednou ptal, pokud je ve scéně 400 uživatelů, změna prostředí každého uživatele to řekne ostatním. Pokud se kombinovaná data nepoužijí, vznikne velmi náročná síťová IO operace, kterou je pro IO systém číslování obtížně zvládnutelný. Proto je nutné data sloučit a odesílat v odpovídajícím zpožděcím intervalu pro aktuální aplikaci. |
Zveřejněno 02.11.2016 9:53:37
|
|
|
