Максимально бесполезное сравнение. Мой скрипт быстрее работает чем твой FastApi. Значит ли это, что FastAPI "не подходит для серьезных проектов". Вот мой скрипт
<?php echo "hi";
Ну как бы исходя и топика здесь вообще все с этим согласны. И только есть сведения, что кто то где то говорил иное. Но раз это в этом топике (ни в виде ссылок, ни в виде цитат) не приведено - значит это (наличие кого то думающего иначе) не существенно , а потому топик как бы не про это становится. Или тут кто то говорил, что ВП абсолютно для всего?
Переписать я сам лично могу на Си или С++ и он гарантированно будет работать быстрее (и у меня даже есть уже готовые некоторые "компоненты" даже могу прям сейчас через FFI подключить). Только вот в чем от этого профит? По сути ты предлагаешь взять в разработку еще 100500 фишек моего сервиса, на которые я сейчас вообще не трачу времени ни секунды. В условиях того, что: команда не большая и доход от сервиса не в триллионах измеряется, это будет очень не разумное решение.
Ну кому как. Это субъективная градация. Мне было интересно сбор данных бирж и выдача в условно реальном времени, да еще в условиях дополнительных технических ограничений. Но это все лирика. Я к тому и говорю: в теме изначально слишком много неизвестных. Определи хоть параметры "серьезного проекта" для целей данного обсуждения.
А ты удосужился почитать про те инструменты, что я привел в сравнении? ;) Думаешь я их просто рандомно выбрал? Почитай.
Тут главное не забыться и не стать в ряды сам знаешь кого.... ;) Уверен FastAPI тоже можно выкинуть из тех же соображений. Вопрос "лишь" во времени.
Ну для начала озвучь критерии "серьезности". Ты ввел этот термин в обсуждение, но его не расшифровал. Лично для меня такие обобщения из той же серии что и разговоры сам знаешь кого про неких программистов умеющих/не умеющих думать своей головой :)
(к слову проект реальный немного его приукрасил, но в целом у меня такой был). Скажем новостной, информационный сайт может быть "серьезным проектом" в твоей шкале координат?
Но последнее не учитываем. Это все развлечение для меня, ничего сложного. Берешься ты сделать это на ВП. Или кто другой хочет доказать мне что ВП для всего годится?
Я даже помогу с ТЗ, Дерзайте. Но на чистом ВП, на плагинах)
Я правильно понимаю, что ты его сделал на чистом FastAPI? Ну я тебе предложу сервис построения выкроек сделать на FastAPi. Ну глупость же. Вопрос лишь в каком объеме (на твоем проекте) ВП может покрыть функционал. Т.е. есть некий уникальный функционал, который ты будешь делать сам в любом случае, а есть функционал обобщенный. Ну и как со свободным временем.
В любом случае. небольшой пример:
Предположим у нас есть серьезный проект. Нам надо выбрать инстурментарий.
95% требующегося функционала уже реализовано в ВП. При этом, если делать на ВП, будет использоваться 99% функционала ВП.
Есть только одна проблема: у нас будет одна страница на которой в реальном времени отражаются данные со множества крипто бирж (с какойто обработкой - являющейся уникальной фишкой проекта) и на эту страниц будет приходить масса пользователей. (ну плюс на главной странице сайта "виджет" с выжимкой из этих данных). Конкертно на эту страницу ожидается что будет просто поток пользователей (там к тому же 100500 фильтров).
Какой подход грамотней:
1. Сделать все полностью на условном FastAPI
2. Сделать все на ВП, но только эту страницу вынести в отдельный сервис
Для начала немного в сторону. Раз уж с первого поста фигурировало "Напишу в сравнении с FastAPI" то меня заинтересовало сравнение этого инструмента с миром PHP (именно с аналогичными инструментами). Сам проводить бенчи поленился (да я и не работал с этими инструментами - велик шанс накосячить и получить не очень корректные результаты) - спросил у ИИ собрать инфу:
FastAPI (Python + uvicorn): ~30,000-50,000 req/sec
PHP (Plain): ~80,000-120,000 req/sec
PHP + RoadRunner: ~150,000-200,000 req/sec
PHP + Swoole: ~180,000-250,000 req/sec
PHP + FrankenPHP: ~160,000-220,000 req/sec
Еще
Simple JSON endpoint:
- FastAPI + uvicorn: ~45,000 req/sec
- PHP 8.3 + FPM: ~95,000 req/sec
- PHP 8.3 + RoadRunner: ~180,000 req/sec
- PHP 8.3 + Swoole: ~210,000 req/sec
Database query endpoint:
- FastAPI + asyncpg: ~8,000 req/sec
- PHP + PDO + FPM: ~12,000 req/sec
- PHP + PDO + RoadRunner: ~25,000 req/sec
Т.е. просадка хорошая получается от запросов в БД и методы решения примерно одни и теже в этом плане. Не зависимо от инструмента. Если же для нас важна исключительно производительность - то как бы стоит оставаться в стане PHP.
Возвращаясь к тормознутости ВП - допускаю, что он генерит на старте много запросов в БД.
Ну и ИИ про него нашел такое:
Немного (при помощи ИИ) поузнавал про внутрянку ВП. Итак тут действительно есть место тормознутости если сравнивать с другими CMS (в частности с Битрикс). В ВП есть хуки - они регистрируются на каждом хите всеми зарегистрированными плагинами, т.е. все активные плагины на каждом хите хоть не много но участвуют. В битрикс аналогом хуков можно считать обработчики событий, которые инициализируются один раз при установке модуля. И соответственно нет необходимости все установленные дергать все активные каждый раз.
Т.е. в ВП более важное значение имеет еще и качество разработки плагинов. Но тут уже стоит это вынести из обсуждения, т.к. дурной код может абсолютно все уничтожить в плане производительности.
Я бы попробовал если бы понял, что конкретно ты хочешь получить от данного обсужедения. Почитываю потому, что тема потенциально интересная, но пока идет сравнение теплого с мягким, и требование доказать что ВП подходит к сферическому коню в вакууме.
Ну, а по сути. При выборе инструмента для применения инструмента на проекте анализируется дофига метрик, а не только "тормознутость". (И Это не критерий какого либо серьезности). И у каждой метрики для каждого проекта свой коэффициент важности. По этому любой вид кеширования это может быть вполне правильное и грамотное решение. Т.е. если тупо принимать решение "аа ВП тормоит, а кеширование это костыль, возьмем фреймворк" - таких решателей надо гнать ссаной тряпкой, т.к. другие критерии могут быть важны.
Вполне рабочее решение (существующее) отдаем статично страницу, а потом хоть отдельные элементы (которые протухли) обновляем. Самое главное если это осмысленно принятое решение, а не уровня "в среднем по больнице это плохо(или хорошо) - значит не применяем (или применяем)".
Причем если проект начинает беспокоить "тормознутость", то всегда есть решения вполне рабочие - выйти в какой то части за пределы штатного функционала. И если ВП решает овердохрена других задач проекта, что не так?
Ты говоришь "ВП тормозит". И чё? Можно было бы и попробовать опровергнуть, но как минимум надо внятые критерии иметь. Тормозит по сравнению с чем? (только не нужны адекватные сравнения, а не FastAPI - который абсолютно другой инструмент и для других целей)
Тормозит на каких задачах?
Ну мне ИИ предложил целых 5 методов, как получить облегченный маршрут из коробки. Включая headless режим, в котором кстати (по заявлениям ИИ) вполне рабочим решением может быть применение FastAPI.
Поясни предлагаемый на замену вариант. Тормознутость есть смысл анализировать в сравнении. Ну и так же уточнение: остальные критерии по которым обычно выбирают инструменты тоже откидывать?
Ну.... А мне смешнее когда с одной стороны заявляют о желании вести технический спор, а с другой делают максимально размыто уводя в зону "сферического коня в вакууме".
