Сервер многопоточности перебил?

Question

В настоящее время я создаю приложение серверного типа, которое будет выполнять обычное прослушивание подключений от внешних клиентов и, когда они подключаются, обрабатывать запросы и т. Д.

В данный момент моя реализация создает пару потоков при каждом подключении клиента. Один поток просто читает запросы из сокета и добавляет их в очередь, а второй читает запросы из очереди и обрабатывает их.

Я в основном ищу мнения о том, считаете ли вы, что все эти темы являются излишними, и важно то, что этот подход вызовет у меня проблемы.

Важно отметить, что большую часть времени эти потоки будут простаивать - я использую маркеры ожидания (ManualResetEvent) в обоих потоках. Поток Reader ожидает, пока сообщение не станет доступным, и, если это так, читает его и помещает в очередь для потока Process. Поток Process ожидает, пока считыватель не сообщит, что сообщение находится в очереди (опять же, с помощью дескриптора ожидания). Если конкретный клиент действительно не забивает сервер, эти потоки будут сидеть в ожидании. Это дорого?

Я провел небольшое тестирование - к нему постоянно подключалось 1000 клиентов - сервер (а значит, более 2000 потоков), и казалось, что он неплохо справляется.

Answer 1

Я думаю, что ваша реализация имеет недостатки.Этот тип дизайна не масштабируется, потому что создание потоков стоит дорого, а количество потоков может быть ограничено.По этой причине большинство реализаций этого типа используют пул потоков .Это позволяет легко ограничить максимальное количество потоков, одновременно управляя новыми подключениями и повторно используя потоки после завершения работы.

Если все, что вы делаете со своим потоком, это помещает элементы в очередь,затем используйте метод ThreadPool.QueueUserWorkItem, чтобы использовать пул потоков .NET по умолчанию.

Вы не дали достаточно информации в своем вопросе, чтобы указать ее для определенного, но, возможно, теперь вам нужен только один другой поток, постоянно выполняющий очистку внизочереди, вы можете использовать дескриптор ожидания, чтобы сигнализировать, когда что-то было добавлено.

Просто убедитесь, что синхронизировал доступ к вашей очереди, иначе все пойдет не так.

Answer 2

Советую использовать следующую скороговорку. Сначала вам нужен пул потоков - встроенный или пользовательский. Есть поток, который проверяет, есть ли что-то доступное для чтения, если да, то выбирает поток Reader Затем читающий поток помещает в очередь, а затем поток из пула обрабатывающих потоков выберет его. это минимизирует количество потоков и минимизирует время, проведенное в состоянии ожидания