Очередь vs мультипоточность

Смотря что ты подразумеваешь под обработкой запроса. Если чисто вычисления - может и имеет смысл однопоточность. Но если есть ожидание (в т.ч. завершения ввода-вывода), то лучше несколько потоков.

Так что есть обработка запроса?

>Так что есть обработка запроса?

Там и вычисления, и общение с базой. Но вычисления занимают в несколько раз больше времени, чем ввод/вывод.

Тогда мне кажется, что будет выигрыш от некольких потоков (двух?). Потому что вычисления второго будут идти тогда, когда идет ввод-вывод первого.

Лучше просто проверь. Надо чтобы не было блокировок одного потока из-за второго, иначе профита может и не быть.

Очередь Вам рано или поздно может выйти боком. Представьте ситуацию, когда клиент сделал запрос и отвалился ничего не сказав (нет FIN, нет RST). Тогда сервер попытается отвечать и будет это делать примерно 10 минут (настройки tcp по умолчанию). Вам это надо?

>Надо чтобы не было блокировок одного потока из-за второго, иначе профита может и не быть.

В теории быть не должно, но таки потестирую, да.

>Представьте ситуацию, когда клиент сделал запрос и отвалился ничего не сказав (нет FIN, нет RST). Тогда сервер попытается отвечать и будет это делать примерно 10 минут (настройки tcp по умолчанию).

Не, такого не возникнет, ибо я не держу tcp-соединение пока сервер рожает результат (потому что иногда это очень долго). Клиент сам возвращается через какое-то время и спрашивает, готов ли результат =)

Одна очередь и два процесса, берущие запросы из этой очереди по одному. Нэ?

FSM per core/CPU

>... Но если есть ожидание (в т.ч. завершения ввода-вывода), то лучше несколько потоков.

Это не всегда так. man poll/select

за poll на lesswatts.org расстреливают.

> за poll на lesswatts.org расстреливают.

Передай им, чтобы застрелились.

> Очевидно, что первый способ экономнее по памяти

У тебя запросы огромного размера?

но вот какой из них быстрее?

Зависит от соотношения нагрузки на ЦП и В/В.

Короче, очередь + конфигурируемое количество процессов, читающих из этой очереди.

Передай им, чтобы застрелились.

+1

Предполагаю, что тут есть путаница между poll[ing] и busy wait

тред читал по диагонали и через слово, но…

всё зависит :)

зависит от объёма свободной памяти… точнее, от объёма памяти, которое вы согласны принести в жертву своему демону :) организовав полностью асинхронный в/в (т.е. POLLIN/POLLOUT через соотв. буфера) можно даже через poll сделать профит перед мультитредной версией. а если epoll заюзать… ;)

/* речь о монопроцессорной системе, если что */

На однопроцессорной системе может и можно получить чуть больше производительность за счет io, но это решение некрасивое, грязноватое. Лучше кошерная очередь.