Зачем это всё надо даже для средного размера интернет магазина, например? FCGI с нормально спроектированной и оптимизированной БД, оптимизированной системой в целом будет на современном сервере за 50$ как пушка пулять, а на сервере за 100$ она простит мне весь мой ретро-говнокод даже:) Мне не попадались заказы на сайты с посещаемостью триллион в секунду, или сколько там держат ваши системы, я хз:)

Более того, я даже никакие теплейты не использую, генерирую и выдаю HTML в скрипте, и таким образом у меня лишних запросов к винту вообще не возникает, всё в ОЗУ, насколько я понимаю.

Да, я понимаю, что как вы говорите делать, веб-сокеты и всё такое это круто, но у меня уже за года выработался мой стиль, который выработался, и он решает мои задачи успешно. Возможно, побыв тут ещё я кое-что пересмотрю, потому что вот сейчас читаю про Mojo и нравится в принципе, и читабельность нравится.

Да, для онлайн игры может какой-то или супер сайта с миллионом хостов в день, наверное нужно и веб-сокеты и всё такое, а для инет магазина средней руки со средней посещаемостью моё решение отлично выполняет функцию.

так то да ), но это уже реализация поверх fcgi, а не посредством fcgi

Знаешь, user experience от кривых чатов, которые чуть ли не только при обновлении страницы показывают новые сообщения (а такие поделки я видел за последний месяц в проде даже не нескольких разных сайтах) -- неудовлетворительный

мне за свои работы не стыдно, на Апворке 5 звезд, top rated, но там правда Перла или не было, или был, где заказчикам было всё равно (парсинг например)

это не то дерьмо с тегами php-style случаем?

Хм... А в чем проблема послать заголовки и статус код?

Надо было сразу написать, что именно в этом проблема.

Понятно, наверное хедер и код послать не проблема. Проблема перейти на этот бинарный протокол, так как web server с fcgi ожидает http запрос.

Да не можно и FCGI разогнать, у меня получалось до 8-10к RPS на ядро FCGI разгонять на pure perl в качестве эксперимента, но смысл в этих велосипедах, если ты гораздо раньше упираешься в базу и нормальные цифры с базой это 100-500  RPS, и проблема вообще не в FCGI и в оптимизации на ассемблере.

В описанном тобой примере проблема в архитектуре

Поясни, что имеешь в виду

Но ведь можно из одного приложения работать с несколькими СУБД :)

Mojo держит 20-25К RPS на ядро. Правильный Pg держит под 100К RPS (и более, на самом деле) при соотношении 95/5 чтения/записи. Не знаю что вы там делаете что у вас 500 RPS это пик.

Много чего делаем, и запросы не самые легкие, а с проблемы с RPS решаем горизонтальным масштабированием, так легче и быстрее. Конечно что-то не получается таким образом решить, но таких случаев единицы.

Да понятно что горизонтальным все решается (Ну, почти все). Но это если можно. Базу уже шардировали?

Я имею ввиду, что нужны: 1. Архитектор решения, 2. Архитектор данных, 3. Системный архитектор, 4. Их совместная работа перед реализацией и тогда не будет такого треша твориться

Достаточно одного архитектора под это все.

Достаточно одного программиста вообще, чтобы сделать все что угодно, правда @mrgood313373 ? :)

Не достаточно. Bus-factor никто не отменял

Так это же применимо и к одному архитектору :р

Я за троих, лично мне всегда так было удобно работать.