Дизайн для Boost ASIO, рабочие потоки SQl-запросы для «практичного» веб-сервера

Я ищу решение для разработки эффективной структуры веб-сервера, где:

  1. Один или несколько потоков ввода-вывода обрабатывают клиентские HTTP-соединения и ввод-вывод TCP.
  2. Несколько потоков выполняют бизнес-обработку (SQL-запросы, файловый ввод-вывод и т. д.)

Все решения для блогов, которые я видел, решают 10000 соединений с рабочими потоками, выполняющими почти нулевую бизнес-логику (т.е. просто записывая данные с использованием async_write). Является ли Boost.Asio HTTP-сервером? 3 решение моей проблемы? Если да, то сколько потоков я должен использовать на ядро?

Мне также интересно узнать, как HTTP Server 3 сравнивается с моделью 1 принимающий поток + пул потоков, используемой mongoose. .


person Anand Rathi    schedule 30.03.2013    source источник
comment
Добро пожаловать в Stack Overflow. Согласно Часто задаваемым вопросам, вы должны пытаться задавать практические вопросы, на которые можно ответить, исходя из реальных проблем, с которыми вы сталкиваетесь. Я ищу предложения, которые, кажется, не соответствуют этой самой воле.   -  person Bo Persson    schedule 30.03.2013
comment
Спасибо, что указали на это, но, пожалуйста, посмотрите дальше этой линии, почему вы считаете, что моя проблема непрактична?   -  person Anand Rathi    schedule 30.03.2013


Ответы (2)


Извините, у меня недостаточно репутации, чтобы использовать комментарии, поэтому я должен опубликовать новый ответ, чтобы внести какой-либо вклад.

OP задает конкретный вопрос о http: //www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/http/server3/. Это пример http-сервера, который запускает пул потоков для обработки http-запросов.

Первоначальный вопрос OP можно было бы переформулировать: «Учитывая серверную машину с набором ресурсов A и рабочую нагрузку, которая потребляет ресурсы B на запрос, сколько потоков я должен выделить в пуле потоков?»

Здесь есть поток: Разумное количество потоков для пула потоков, работающего в Интернете запросы на обслуживание с аналогичным обсуждением (относительно пулов потоков Java), но это обсуждение, похоже, не приводит к какому-либо окончательному ответу.

Вот пример краткого руководства по планированию емкости в «старомодном стиле мэйнфреймов 1970-х годов», которое я изучил в школе: http://www.cs.umb.edu/~eb/goalmode/primer.pdf.

В этом случае вы можете создать простую модель, например:

У вас есть средняя скорость поступления запросов, X. Для каждого запроса вы потребляете определенное среднее количество ресурсов ЦП (в единицах времени) S_c и среднее количество времени, затрачиваемое на ожидание завершения запросов к диску, S_d. Таким образом, каждый поток занимает среднее время S_c + S_d, прежде чем он будет возвращен в пул потоков. (Вам нужно будет измерить это.) Таким образом, в среднем вы ожидаете, что вам потребуется по крайней мере N = X * (S_c+S_d) потоков, чтобы входящие потоки не стояли в очереди в пустом пуле потоков. На самом деле вы можете захотеть выделить небольшое количество N (например, 3N) потоков, чтобы иметь возможность справляться с всплесками того или иного типа.

Но количество потоков в пуле на самом деле не является интересным ограничением. Интересным ограничением является либо общий объем ЦП, либо общий объем доступной пропускной способности диска. Предположим, что каждый запрос требует обработки ЦП в течение 3 секунд, и у вас есть система с 12 ядрами. Таким образом, за любой 3-секундный период вы должны обрабатывать 12 одновременных запросов. Таким образом, средняя скорость поступления более 12/3 = 4 запроса в секунду приведет к насыщению вашего ЦП. (Аналогичный расчет пропускной способности вашего диска.)

Итак, на самом деле вам предстоит выяснить следующее: учитывая мою ожидаемую скорость поступления запросов, X, а также количество ресурсов ЦП и диска, потребляемых каждым запросом, сколько процессора и диска мне следует приобрести?

person Wandering Logic    schedule 30.03.2013
comment
Спасибо, @Wandering Logic. Также мой вопрос был связан с тем, как лучше всего использовать ASIO для HTTP-приложений, где рабочий должен выполнять длительную блокировку, например, sql-запрос, файловый ввод-вывод и т. д. и т. д. - person Anand Rathi; 30.03.2013
comment
Если вы уже создаете несколько потоков для каждого http-запроса, то я не вижу никакой дополнительной ценности для asio. ASIO позволяет одному потоку обрабатывать множество запросов, не беспокоясь об порядке их поступления. Обычно это значительно усложняет вашу бизнес-логику. (Ваш последовательный порядок действий в вашей бизнес-логике делится на кучу продолжений, которые передаются в качестве обработчиков возврата для асинхронных операций ввода-вывода.) - person Wandering Logic; 30.03.2013
comment
для запроса на чтение ничего особенного, но позже для записи данные должны быть подготовлены, а затем поставлены в очередь. Моя проблема после чтения, подготовки данных. [Вопрос в том, как различные асинхронные фреймворки решают эту проблему эффективно и элегантно, любые ссылки будут полезны] Мне все равно, в каком порядке это написано. - person Anand Rathi; 30.03.2013
comment
boost.org/doc/libs/1_53_0/doc/html/boost_asio.html. Но asio ужасен для бизнес-логики. Вместо этого: для каждого http-запроса создайте поток (или поместите запрос в очередь, которая будет обслуживаться пулом потоков). Каждый поток будет выполнять бизнес-логику для одного запроса. Каждый поток будет выполнять блокирующие операции ввода-вывода, но это не имеет значения, поскольку все остальные запросы обслуживаются асинхронно другими потоками. С потоками вы можете использовать локальные переменные, которые хранят данные при блокировке вызовов ввода-вывода. С asio вам нужно явно управлять всем этим состоянием. - person Wandering Logic; 30.03.2013
comment
Спасибо, сделаю, Изучив большинство вариантов, почти пришел к выводу ‹br/› A] Один поток для epoll ‹br/› B] Пул для бизнес-логики ‹br/› C] Очередь между IO thread и пул ‹br/› D] канал между потоком ввода-вывода и пулом для пробуждения потока ввода-вывода для записи данных ‹br/› E] прием и чтение и запись клиента выполняются потоком ввода-вывода ‹br/› И я предполагаю, что ngix и lighthttpd следуют тому же? - person Anand Rathi; 31.03.2013

Изучив большинство вариантов, я почти пришел к выводу
A] Один поток для epoll
B] Пул для бизнес-логики
C] Очередь между потоком ввода-вывода и пулом
D] канал между потоком ввода-вывода и пулом для пробуждения потока ввода-вывода для записи данных
E] прием и чтение и запись клиента выполняются потоком ввода-вывода
И я предполагаю, что ngix и lighthttpd следуют одному и тому же?

person Anand Rathi    schedule 31.03.2013
comment
Я не уверен, что такое epoll. Я бы использовал один поток для прослушивания и принятия() новых подключений, а затем использовал Очередь сообщений, чтобы передать только что принятый дескриптор файла в пул потоков, а затем вернуться к accept() следующего . Затем пусть поток в пуле потоков выполняет всю клиентскую логику и записывает данные, а затем возвращается в очередь сообщений для ожидания следующего клиента. Просто используйте мьютекс для защиты записи. Это будет сериализовать их. - person Wandering Logic; 31.03.2013