2016-03-22 5 views
0

Я хочу написать серверную программу, которая принимает входящие соединения и обрабатывает полученные запросы. Первая идея появилась у меня в голове - использовать неблокирующий сокет с epoll() или select().Эффективность асинхронного неблокирующего серверного сокета

Например, когда возвращается epoll(), он дает мне массив сокетов с доступными событиями ввода-вывода. Затем мне нужно перебрать массив сокетов для отправки и получения данных, как только буфер будет полностью получен или отправлен, выполняются функции обратного вызова. Это также техника, наиболее обсуждаемая в Интернете.

Однако, если я использую эту технику, моя программа будет поддерживать все остальные сокеты, ожидая, когда она будет иметь дело с одним клиентским соединением. Разве это неэффективный способ пойти, если запрос клиента занимает много времени?

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

Таким образом, , мой вопрос: Как создать эффективную серверную программу, если она должна обрабатывать тяжелую рабочую нагрузку?

Спасибо.

+0

Waaaay для широкого. – SergeyA

+0

@SergeyA Я не переделал, что это была такая широкая тема. Но я думаю, что у меня уже есть мой ответ, и хорошая статья для чтения. Спасибо. – vesontio

ответ

1

Миллион долларов вопросы с миллионами различных компромиссов. Для тех, которые получают Monty Python ...

https://www.youtube.com/watch?v=pWS8Mg-JWSg

Назад к реальности ... Apache2 может обрабатывать большой объем работы, Nginx может обрабатывать большой объем работы, поэтому может Node, Tomcat, Jetty, JBoss, Нетти ... На самом деле любой из известных серверов приложений, используемых сегодня, и несколько менее известных, могут обрабатывать тяжелые рабочие нагрузки, и все они используют различные комбинации потоков, событий и процессов для этого. Некоторые языки, например, Erlang или Go и т. Д., Позволяют вам легко создавать высокопроизводительные серверы приложений в нескольких сотнях строк кода.

Хотя устарели теперь следующая страница содержит большую информацию о том, почему это не простая задача ...

http://www.kegel.com/c10k.html 

Вместо того, чтобы беспокоиться о производительности теперь получить что-то работает, тест тогда спросить, как сделайте это быстрее ... если вы были умны и убедились, что у вас есть модульный дизайн, свопинг его частей будет относительно легким, то посмотрите на то, что Apache сделал с MPM, сменный двигатель с совершенно разными характеристиками производительности и т. д.

Как только ваш сервер будет превосходить любой из вышеперечисленных в тестах ваш ответ t o этот вопрос, скорее всего, будет принят.

+0

Спасибо за ссылку. – vesontio

1

Тяжелая рабочая нагрузка является вводящим в заблуждение термином, и в конце концов, это не диктует, как вы должны проектировать свою систему. Главная проблема здесь - это отзывчивость и ее требования. Если обработка одного запроса занимает много времени, и вы не хотите голодать другим клиентам (чего, вероятно, нет), то, по-видимому, ни один проект нитей не сделает. По крайней мере, у вас должен быть поток (или один на каждого клиента), который каким-то образом обрабатывает запрос, даже если только уведомляет клиента о том, что запрос обрабатывается.

+0

Благодарим вас за ответ. – vesontio