Size: a a a

2021 January 14

DF

Denis F in Modern::Perl
Александр Поволоцкий
Другого чего?
Повторяю свой тезис.
middleware современного веб-сервера при генерации ответа 80-90% времени ждет. Замена PP на XS приведет к тому, что ждать  middleware будет ... точно так же. То есть, при реальном сценарии замена PP на XS даст, ну, скажем, 20% прироста производительности к 20% времени работы собственно миддла - 4%, что в целом на уровне погрешности измерения.
Т.е. на уровне движка эта замена даст примерно ничего.
Единственное место, где XS может заметно порешать - это рендеринг страницы, если он делается на сервере.
Асинк же.  Ждать будет не один запрос,  а пару сотен. Так что утилизация сервера сильно улучшится
источник

W

Warstone in Modern::Perl
Александр Поволоцкий
Специально для любителей софтскиллов. Mojo может и не ждать, но от момента запроса до момента выдачи ответа проходит время. Как так - великая загадка. И вот Mojo от этого времени потребляет 5-20%. Т.е. как ни оптимизируй, а общее время от запроса до ответа заметно не возрастет.
Специально для любителей софтскиллзов, ресурсы, которые необходимы на обработку запроса, в случае с Mojo в десятки раз меньше чем тот сферический сервер в вакууме о котором вы говорите.
источник

W

Warstone in Modern::Perl
И ваши 4% превращаются в 40%
источник

IA

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

IA

Ivan Avseyanko in Modern::Perl
Вы оба правы )
источник

b

basiliscos in Modern::Perl
Александр Поволоцкий
Кстати, за что? Очень логичная штука
За то, что это toolbox: юзают свою систему OOP, вместо Moo или ещё чего-нить минималистичного, написали свой JSON, свою ходилку по DOM'у, свой ивент-луп, свой рендерщик темплейтов. И ещё много чего "из коробки" дают, что не надо было бы.
источник

W

Warstone in Modern::Perl
Ivan Avseyanko
Кхм, господа, мне кажется вы мыслите в разных парадигмах. Абонент номер один смотрит со стороны клиента, где из времени ответа на запрос очень много времени уходит на ожидание io. Абонент номер два смотрит со стороны сервера, который, в общем-то совершенно не обязан ждать ответа каких то левых БД, и может сделать что-то полезное.
Эм... Александр просто переодически меняет совю сторону зрения и то говорит о том что сервер стоит то со стороны пользователя. Не может определиться, наверно.
источник

R

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

W

Warstone in Modern::Perl
^_^
источник

АП

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

W

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

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

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

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

SZ

Sergey Zhmylove in Modern::Perl
Александр Поволоцкий
Я не готов придумать сайт, который не упирался бы в БД и при этом не сводился бы к генератору статики.
Wolframalpha
источник

R

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

VG

Vadim Goncharov in Modern::Perl
понял, не буду пользоваться DBIx ))
источник

R

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

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

АП

Александр Поволоцкий... in Modern::Perl
Sergey Zhmylove
Wolframalpha
Там модули просятся в XS. Но это реально исключение, и в XS идет приложение, а не веб-обвязка
источник

SZ

Sergey Zhmylove in Modern::Perl
Александр Поволоцкий
Там модули просятся в XS. Но это реально исключение, и в XS идет приложение, а не веб-обвязка
Любой конвертер также не является генератором статики и не упирается в бд
источник

АП

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

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

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

>Если все это вертится на своем оборудовании - большого эффекта не будет. Хотя, да, утилизация сервера возрастет, и хорошо
У вас уменьшится Cost-Per-Request, так как уменьшатся требования к ЦПУ и памяти, эти ресурсы вы можете потратить или для уменьшения парка серверов или на развитие проекта
Вы все время путаете ... да примерно все сразу.
Если у нас основная нагрузка - на нашем оборудовании (та же БД), то снижение нагрузки на наименее нагруженную часть мидл нам общую нагрузку сильно не уменьшит. А если на чужом - то даст заметный эффект.
источник

W

Warstone in Modern::Perl
Александр Поволоцкий
Вы все время путаете ... да примерно все сразу.
Если у нас основная нагрузка - на нашем оборудовании (та же БД), то снижение нагрузки на наименее нагруженную часть мидл нам общую нагрузку сильно не уменьшит. А если на чужом - то даст заметный эффект.
Причем тут оборудование?.. Или у вас небыло проектов с 10+, хотя-бы, серверами?
источник

АП

Александр Поволоцкий... in Modern::Perl
Sergey Zhmylove
Любой конвертер также не является генератором статики и не упирается в бд
Если мы занимаемся пережимом аудио/видео/картинок, например, то нужно просто убирать в XS само пережимало. Нагрузка, вносимая разборщиком/сборщиком http, роутером и прочим - в целом пренебрежимо мала
источник