Синхронизация по сравнению с асинхронной производительностью сокетов в.NET
Все, что я считал о сокетах в.NET, говорит, что асинхронный шаблон дает лучшую производительность (особенно с новым SocketAsyncEventArgs, который экономит на выделении).
Я думаю, что это имеет смысл, если мы говорим о сервере со многими соединениями клиента где не возможный выделить один поток для каждого подключения. Затем я вижу преимущество использования потоков ThreadPool и получения асинхронных обратных вызовов на них.
Но в моем приложении, я - клиент, и я просто должен слушать один сервер, отправляющий тиковые данные рынка по одному соединению TCP. Прямо сейчас я создаю единственный поток, устанавливаю приоритет на Самый Высокий, и Сокет вызова. Получите () с ним. Мои блоки потока на этом вызове и просыпаются, после того как новые данные прибывают.
Если я должен был переключить это на асинхронный шаблон так, чтобы я получил обратный вызов, когда существуют новые данные, я вижу две проблемы
Потоки пула потоков будут иметь приоритет по умолчанию, таким образом, будет казаться, что они будут строго хуже, чем мой собственный поток, который имеет Самый Высокий приоритет.
Я должен буду все еще отправить все через единственный поток в какой-то момент. Скажите, что я получаю обратные вызовы N в почти то же время на различных потоках пула потоков N, уведомляющих меня, что существуют новые данные. Массивы байтов N, что они поставляют, не могут быть обработаны на потоках пула потоков, потому что нет никакой гарантии, что они представляют уникальные сообщения данных рынка N, потому что TCP на основе потоков. Я должен буду заблокировать и поместить байты в массив так или иначе и предупредить о некотором другом потоке, который может обработать то, что находится в массиве. Таким образом, я не уверен, что распараллеливает наличие N пул потоков, покупает меня.
Я думаю об этой несправедливости? Существует ли причина использовать Асинхронную скороговорку в моем конкретном случае одного клиента, подключенного к одному серверу?
ОБНОВЛЕНИЕ:
Таким образом, я думаю, что неправильно понимал асинхронный шаблон в (2) выше. Я получил бы обратный вызов на одном рабочем потоке, когда были доступные данные. Затем я начал бы, другой асинхронный получает и получает другой обратный вызов и т.д. Я не получил бы обратные вызовы N одновременно.
Вопросом все еще является то же все же. Есть ли любая причина, что обратные вызовы были бы лучше в моей определенной ситуации, где я - клиент и только подключенный к одному серверу.
3 ответа
Самая медленная часть вашего приложения будет сетевое общение. Очень вероятно, что вы почти не повлияете на производительность для одного потока, одного клиента соединения, настроив такие вещи. Сама сетевая коммуникация затмевает все остальные вклады во время обработки или переключения контекста.
Допустим, я получаю N обратных вызовов почти одновременно на N разных потоках пула потоков, уведомляющих меня о появлении новых данных.
Почему это произойдет? Если у вас есть один сокет, вы Начинаете операцию на нем для получения данных, и вы получите ровно один обратный вызов, когда он будет выполнен. Затем вы решаете, выполнять ли еще одну операцию. Похоже, вы слишком усложняете его, хотя, возможно, я слишком упрощаю его в отношении того, что вы пытаетесь сделать.
Вкратце, я бы сказал: выберите простейшую модель программирования, которая даст вам то, что вы хотите; учитывая варианты, доступные в вашем сценарии, они вряд ли существенно повлияют на производительность, какой бы из них вы ни выбрали. С моделью блокировки вы «тратите впустую» поток, который мог бы выполнять некоторую реальную работу, но эй ... может быть, у вас нет для этого реальной работы.
Насколько я понимаю, вы здесь клиент , имеющий только одиночное соединение.
Данные по этому соединению поступают по порядку, потребляются одним потоком.
Вы, вероятно, потеряете производительность, если вместо этого будете получать небольшие суммы в отдельных потоках, чтобы вы могли позже собрать их в сериализованном - и, следовательно, как однопоточном - способе .
Много шума из ничего.
На самом деле вам не нужно это ускорять, возможно, вы не сможете.
Однако вы можете отправлять рабочие единицы другим потокам после их получения. Для этого SocketAsyncEventArgs не требуется. Это может ускорить работу.
Как всегда, измеряйте и измеряйте.
Кроме того, то, что вы можете, не означает, что вы должны.
Если производительности достаточно в обозримом будущем, зачем усложнять ситуацию?
Правило номер один для повышения производительности: старайтесь улучшать производительность только тогда, когда это необходимо.
Я вижу, вы упоминаете стандарты, но никогда не упоминаете о проблемах, если у вас их нет, то вам не нужно беспокоиться о том, что говорят стандарты.