Dmitri Kuzmenko wrote:
Но это всё ещё не то, чего хочется. Сейчас проблема в том, что
суперсервер
из за кривизны кода плохо параллелится по разным потокам.
он вообще не параллелится, и не из-за кривизны, а из-за архитектуры.
Насколько я помню из времён ковыряния к коде FB1.0 там
1) кооперативная многозадачаность. FB сам переодически переключается на
другой запрос.
2) много глобальных переменных.
3) блокировки
4) нереентабельный код.
В принципе на истинный параллелизм можно и забить, если бы кооперативная
многозадачность работала бы более качественно.
Давайте сделаем такую архитектуру: гибрид классика и супера.
ты бы пару лет назад это написал. А теперь уже поздно.
"Никогда не поздно". Если посмотреть на перспективу, то даже если
суперсервер будет идеально параллелиться по ядрам, то полезно было бы
иметь возможность запускать несколько его процессов для:
1) надёжности от программных сбоев
2) загребания большего количества памяти (32бит лимит)
3) перспектив кластеризации и работы а железе где нет глобальной SMP.
с какого буя? С приоритетами уже баловались, на классике.
Запускаем на супере:
1) тяжёлый долгоиграющий запрос
2) в другом коннекте пускаем сверхкороткий.
В результате скорость отклика на короткие запросы существенно падает.
Для тяжёлого запроса пофиг сколько он будет выполняться 1 минуту, или 2.
А для коротких скорость отклика критична.
Поэтому введение приоритета явного или неявного напрашивается.
