Нижче наведено короткий огляд проблем реалізації високопродуктивного сокетного компонента: якщо вам потрібно працювати лише з тисячами одночасних додатків, ви можете звернути увагу на написання коду, але потрібно мати справу з десятками тисяч або десятками тисяч одночасних додатків. Вважається, що підсумок наступних питань значно допоможе у написанні цієї заявки.
SocketAsyncEventArgs
Цей об'єкт надається після .NET 2.0 sp1 і головним чином використовується для реалізації високопродуктивної обробки даних у сокеті (для детальнішого вступу можна перейти до MSDN). Цей об'єкт пропонує три способи налаштування буферів для надсилання та отримання відповідних відправлень: SetBuffer(Int32, Int32), SetBuffer(Byte(), Int32, Int32, BufferList, перші два не можуть співіснувати з останнім ( MSDN пояснює чому). Коли ви встановлюєте буфер, чи то SetBuffer(Byte(), Int32, Int32) чи BufferList, намагайтеся встановити його лише один раз на екземпляр SocketAsyncEventArgs протягом усього життя програми, оскільки це налаштування може бути дуже ресурсомістким. Рекомендується встановлювати буфер даних через SetBuffer(Byte(), Int32, Int32) під час створення SocketAsyncEventArgs, а потім використовувати SetBuffer(Int32, Int32) для обробки. Коли ви хочете встановити BufferList, краще не змінювати <byte>джерело байтів[] на яке посилається IList<ArraySegment>. Якщо це змінити, SocketAsyncEventArgs переназначить буфер і вплине на ефективність.
Пул SocketAsyncEventArgs
Як згадувалося вище, намагайтеся не змінювати буфер, на який посилається SocketAsyncEventArgs, наскільки це можливо, щоб досягти цієї мети. Тому необхідно побудувати пул додатків SocketAsyncEventArgs і максимально ініціалізувати об'єкт SocketAsyncEventArgs на початку програми. Окрім зменшення створення SocketAsyncEventArgs, побудова пулів також значно економить пам'ять. Головна причина в тому, що ви не можете знати, наскільки велике кожне повідомлення, звісно, можна встановити максимальний ліміт повідомлення перед проектуванням, а потім встановити буфер, що відповідає SocketAsyncEventArgs. Однак це велика трата пам'яті, адже не всі повідомлення мають максимальну довжину. Виділяти відповідний розмір буфера для SocketAsyncEventArgs, забезпечувати виклики через пули та гнучко записувати повідомлення на один або кілька SocketAsyncEventArgs, або зберігати кілька повідомлень в одному SocketAsyncEventArgs для обробки.
Черга
Я бачу, що багато практик передбачають відкриття потоків безпосередньо або кидання їх у пул потоків після отримання даних, що дуже погано, бо це не контролює роботу потоків, включаючи очікування потоків. З користувацькими потоками + чергами ви можете контролювати, скільки потоків відповідає за яку роботу, і черга працюватиме лише в черзі; Не буде великої кількості потоків або великої кількості рядків, що призведе до втрати ресурсів операційною системою через планування потоків.
Затримка консолідації даних
Затримка передачі даних при злитті — це спосіб вирішити проблему надмірних мережевих операцій з IO, що не використовується в багатьох ситуаціях, але є поширеним на ігрових серверах. Хтось уже ставив мені питання: якщо в сцені 400 користувачів, зміна середовища кожного користувача покаже іншим користувачам. Якщо об'єднані дані не використовувати, це призведе до дуже небезпечної операції з мережевим введенням, що важко передати системі номерів операцій IO. Тому необхідно об'єднувати та надсилати дані в межах відповідного інтервалу затримки для поточного застосування. |
Опубліковано 02.11.2016 09:53:37
|
|
|
