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

Question

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

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

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

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

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

0

blocking boost boost-asio c++multithreading

Решение

Другие решения

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

0

Источник

Accepted Answer

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

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

Исходный вопрос О.П. можно перефразировать: «учитывая серверную машину с набором ресурсов 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, а также количество процессора и диска, потребляемых каждым запросом, сколько процессоров и дисков я должен купить?

1