Чтение через SendAsync, BeginAsync метод иллюстрации Socket с, я понял, что это было предложено объединить SocketAsyncEventArgs примеры говорят, что это лучше, чем BeginXX, EndXX подход, так как асинхронные каждый вызов создает экземпляр IAsyncResult..NET Pooling IAsyncResult объектов
Я думал, что это не была отличная практика для объединения объектов, которые могут быть легко созданы (например, SocketAsyncEventArgs). Размещение объектов довольно быстро, и GC оптимизирован для эффективного управления короткими живыми объектами. Я попробовал это реализовать механизм объединения, чтобы увидеть, как он выполняется, на самом деле распределение выполняется быстрее на простых объектах, которые ничего не делают, кроме инкапсуляции некоторых данных в ctor. (Ну, это было похоже на профилирование СУБД, отправив миллиарды SELECT 1 заявлений, вот почему я здесь.)
Я не спрашиваю, что лучше, я считаю, что профилирование фактического приложения даст ответ, но просто любопытно о преимуществах объединения простых коротких живых объектов. Лучшая производительность GC? Низкая фрагментация памяти? Стоит ли учитывать это во время проектирования?
От MSDN
Главной особенностью этих усовершенствований является предотвращение повторного распределения и синхронизации объектов при больших объемах асинхронного сокета ввода/вывода. Начальный/конечный шаблон проектирования в настоящее время реализован по System.Net.Sockets.Socket класс требует, чтобы для каждой асинхронной операции сокета был назначен объект System.IAsyncResult .
В новых усовершенствованиях класса System.Net.Sockets.Socket асинхронные операции сокетов описываются многоразового SocketAsyncEventArgs объектов выделены и поддерживаются приложения. Высокопроизводительный сокет приложений лучше всего подходит для операций с перекрывающимися гнездами , которые должны быть поддерживаются . Приложение может создать столько объектов SocketAsyncEventArgs, которые ему нужны . Например, если сервер приложения должны иметь 15 сокета принимать операции выдающихся во всех раз, чтобы поддерживать входящие скорости соединения клиента , он может выделить 15 многоразовых SocketAsyncEventArgs Объектов для этой цели.
Спасибо.
Где вы прочитали предложение? MSDN? Не могли бы вы связать его? Во-вторых, какой сокет-код вы работаете? Будет ли много клиентов или некоторых клиентов с большими данными. Лично я бы избегал добавлять дополнительную сложность, если это явно не требуется, и во многих пулах приложений это просто не стоит. –
@dr. зло Добавил ссылку. Это около 100 клиентов, отправляющих 3-5 небольших пакетов в секунду. Я также создаю объекты «Message» для каждого пакета, поэтому мне было интересно, следует ли их объединять. –
Я думаю, что вы будете более чем на 100 клиентов 3-5 пакетов в секунду. Я не думаю, что вам нужно также объединить сообщение (просто убедитесь, что оно правильно настроено). Управление памятью .NET может обрабатывать гораздо больше, чем легко, без влияния производительности. –