Pavel Zarubin

Добрый день, я уже больше двух лет не поддерживаю данное дополнение и не в курсе по поводу его текущей кодовой базы, все вопросы задавайте в поддержку modstore

Добрый день, я уже больше двух лет не поддерживаю данное дополнение и не в курсе по поводу его текущей кодовой базы, все вопросы задавайте в поддержку modstore

ну для меня будет)

Достаточно просто загуглить «php framework banchmarks»
тык
Исходя из этого бенчмарка Lucinda быстрее laravel в 47 раз

а почему не является?

За что я ненавижу Eloquent ORM а также тысчи подобных статей и обсуждений к ним

ну это искусственный тест, а на реальных проектах заметно?

Конечно еще сильнее становится заметно чем обычный hello world, чем больше связей, чем больше данных тем более заметно, но это все не критично, laravel — идеальный php фреймворк, его выбирают за простоту работы, за то, насколько просто найти разработчика на него и насколько быстро можно реализовывать фичи, если недостаточно laravel'я, то стоит задуматься не о других фреймворках, а о других ЯП уже

а на slave

А как slave должен ускорить?

еще и кешированием

Оооо… тут вообще можно бесконечно рассуждать, говоря о кешировании, вы как, батенька кешируете? Например если ты кешируешь в файловую систему, то, забрать из fs будет сильно дороже по ресурсам и времени, нежели забрать из БД с правильными индексами. По другому обстоят дела если это memcached или redis, но тут будут и другие подводные камни, мы же говорим о базовой реализации, не так ли?

Вообще, думаю не будет ни для кого откровением, что laravel — один из самых медленных php фреймворков, он ориентируется не на скорость, он ориентируется на пользователей и простоту использования и ради этого жертвует скоростью

На тот момент, когда я ушел в laravel (это была еще 6.х версия) modx показывал на голой странице с выборкой из бд 1000 элементов гораздо меньше потребления и по памяти и по CPU, как сейчас дела обстоят не знаю, но подозреваю что +- также, да это и не удивительно, laravel из коробки содержит логики в несколько раз больше, чем modx, да и PSR ООП само по себе тяжелее, нежели легаси modx
Та же eloquent содержит в себе сильно больше логики и обвязки (потому что хочет быть похожей на ORM, но ей не является) чем пусть и кривоватый, но конструктор запросов под названием pdoTools

профит скорее всего есть

Хотелось бы услышать, какой?
Боюсь что он будет даже отрицательный, нежели положительный
Не меняя подход к выборке (например параллельные запросы), не меняя архитектуру базы данных, не проставляя индексы какое время вы хотите выиграть? А прослойка в виде api скорее всего только тормозит результаты

Странное решение честно говоря
1) Зачем тут использовать laravel? Какие он преимущества даст, кроме собственного удовлетворения что теперь то «все красиво»
2) В быстрой фильтрации важнее правильные индексы и в принципе архитектура бд, laravel на это никак не повлияет
3) «Микросервисы» на PHP сложно назвать микросевисами, хотя бы потому, что они обмениваются по json api (вместо gRPC например) который медленный и сильно нагружает сеть, я уже молчу о том, что сам laravel сильно тяжелее того же modx

По мне лучше бы показал как интегрировать какой нибудь легковесный полнотекстовой поиск, по типу meilisearch и на основе него уже построить фильтрацию, а уже что там будешь использовать для обращения к api meilisearch laravel, modx или нативный php уже не важно
Так хотя бы профит будет

Судя по всему так и есть, решилось бы выносом процесса скриншота в отдельный поток, и дальнейшую обработку «статусов обработки» но это уже немного выходит за рамки эксперемента на один вечер) Но за тестирование спаисбо)

Круто! Но SVG похоже не хавает)

Да не было задачи сделать работающую на 100% штуку, была задача сделать штуку, с которой не справится php) На весь эксперемент был всего лишь один вечер)

Puppeteer

Очень много работал с пуппетером и его аналогами в ноде, go в этом плане сильно удобнее т.к. может группировать процессы на отдельные потоки, может например запустить браузер и держать его запущенным а каждую вкладку обрабатывать отдельным потоком, убивается поток — убивается вкладка и никаких memory leak

modx.pro/components/19348 я хз насколько он сейчас рабочий но с десяток сайтов я им правил

Нет, обычный полнотекстовой поиск, там не такие товары и не такой заказчик чтобы заморачиваться с фильтрами и фасетным поиском) Наверное первый, кто дойдет до задачи фасетного поиска на этом проекте, просто перетащит его на какой нибудь условный ларавель, чтобы не иметь в будущем проблем)))

Все стандартно, кроме прикрученного эластика для поиска все нормально справляется если к этому вопрос )

примерно так будет.

Ну вот об этом я и говорю, какой смысл использовать тогда newQuery если все то же самое и в таком же количестве можно написать напрямую в SQL?

getCollection, который предназначен не совсем для подобных дел

А для каких дел он тогда предназначен, если не может построить оптимальный запрос?

когда стоило последний сравнивать с более подходящим конкурентом – newQuery.

Не знаю, я все таки считаю что сравнивать с newQuery не корректно, newQuery просто транслирует php команды в SQL код, он не автоматизирует ничего и не упрощает

Я ж и попросил показать код на newQuery, мне не очень понятно зачем я должен его использовать, если я могу написать то же самое по объему и сложности на обычном SQL

Очевидно что не будет, а еще она также будет минимальна если все эти лефт джоины прописать руками в mysql, только вот newQuery так себе билдер
И код на newQuery будет скорее всего похож по количеству и структуре на выходной SQL

почему сравнивается getCollection, а не с newQuery

Потому что в случае с getCollection не надо джойнить tv, а можно их получить через getTVValue через модель собственно

Я честно говоря уже настолько долго не работал с modx что понятия не имею что за newQuery, если есть возможность и время, я был бы рад увидеть пример подобного запроса на newQuery, если там надо руками джойнить таблицы с тв, то какой в нем смысл по сравнению с написанием обычного SQL?
Главная причина почему пришлось писать билдер, это адская структура таблиц тв полей и сложность джоина каждого из параметров

Проверьте сейчас или минут через 15, должно появится, дополнение давно не проверялось, было бы неплохо чтобы вы еще и отписались работает ли оно вообще

Да, только вот не смотря на не малое количество проектов, не смотря на гораздо большее количество разработчиков, чем в modx, и особенно их уровень, никто тянуть ее не стал

Когда то также думали про Yii, фреймворки умирают быстрее CMS и им проще это сделать