Асинк же.  Ждать будет не один запрос,  а пару сотен. Так что утилизация сервера сильно улучшится

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

И ваши 4% превращаются в 40%

Кхм, господа, мне кажется вы мыслите в разных парадигмах. Абонент номер один смотрит со стороны клиента, где из времени ответа на запрос очень много времени уходит на ожидание io. Абонент номер два смотрит со стороны сервера, который, в общем-то совершенно не обязан ждать ответа каких то левых БД, и может сделать что-то полезное.

Вы оба правы )

За то, что это toolbox: юзают свою систему OOP, вместо Moo или ещё чего-нить минималистичного, написали свой JSON, свою ходилку по DOM'у, свой ивент-луп, свой рендерщик темплейтов. И ещё много чего "из коробки" дают, что не надо было бы.

Эм... Александр просто переодически меняет совю сторону зрения и то говорит о том что сервер стоит то со стороны пользователя. Не может определиться, наверно.

Коля, получи ачивку "тролль 81-го уровня". Заслужил!

^_^

Warpstone настолько увлечен своей крутизной, что не очень понимает собеседника и не горит желанием.
Это бывает.
Даже если PP -> XS резко повысит призводительность собственно мидла, основных потребителей времени и проца это никак не коснется.
Если большая часть времени запроса - обращение к сторонним сервисам, эффект будет.
Если все это вертится на своем оборудовании - большого эффекта не будет. Хотя, да, утилизация сервера возрастет, и хорошо

Ну давайте разберем по пунктам...
>Даже если PP -> XS резко повысит призводительность собственно мидла, основных потребителей времени и проца это никак не коснется.

Вы в миддл ORM, агента, клиенты для внешних сервисов включаете? Если да, то ваше утверждение неверно. Если нет, то вы не правы - это такое-же middleware.

> Если большая часть времени запроса - обращение к сторонним сервисам, эффект будет.
Как раз тут будет минимальный. Так как само время обращения не изменится (ну или совсем чуть-чуть уменьшится, разве что ответ от внешнего сервиса "большой" и его клиенту долго обрабатывать.

>Если все это вертится на своем оборудовании - большого эффекта не будет. Хотя, да, утилизация сервера возрастет, и хорошо
У вас уменьшится Cost-Per-Request, так как уменьшатся требования к ЦПУ и памяти, эти ресурсы вы можете потратить или для уменьшения парка серверов или на развитие проекта

Wolframalpha

Вот вам такой пример, что будет, если не пользоваться плохо написанным кодом. Он про DBIx. Есть в проекте много общих данных, которые надо загрузить на старте из БД в память, проверить, сконвертировать, создать различные структуры для удобного и быстрого доступа и т.п. В процессе работы этой части программы съедается 500+ МБ оперативки. Работало это 45 секунд. С каждым годом данных все больше и больше, грузятся все медленнее, каждый год проводятся оптимизации, но что-то слабо помогало. В этот раз удалось сократить время загрузки до 13 секунд. Как? Частичный отказ от услуг DBIx. Даже если данные уже получены из БД, получение строк relation отнимало неимоверное количество времени. В итоге, запросы к БД не изменились, количество данных не поменялось, а время ушло в 3 раза меньше.

понял, не буду пользоваться DBIx ))

Это я к тому, кто говорит "ну мы же в БД долго тупим". А точно? Попробуйте трассировку, профилирование.

Другой пример. Структура многоуровных хешей в PP съедала 250 МБ. Удалось переводом в XS сократить ее до 70 МБ и ускорить на 25%.

Там модули просятся в XS. Но это реально исключение, и в XS идет приложение, а не веб-обвязка

Любой конвертер также не является генератором статики и не упирается в бд

Вы все время путаете ... да примерно все сразу.
Если у нас основная нагрузка - на нашем оборудовании (та же БД), то снижение нагрузки на наименее нагруженную часть мидл нам общую нагрузку сильно не уменьшит. А если на чужом - то даст заметный эффект.

Причем тут оборудование?.. Или у вас небыло проектов с 10+, хотя-бы, серверами?

Если мы занимаемся пережимом аудио/видео/картинок, например, то нужно просто убирать в XS само пережимало. Нагрузка, вносимая разборщиком/сборщиком http, роутером и прочим - в целом пренебрежимо мала