Pavel Zarubin

Pavel Zarubin

С нами с 07 сентября 2016; Место в рейтинге пользователей: #17
Отправить деньги
Pavel Zarubin
23 января 2023, 15:37
0
Добрый день, я уже больше двух лет не поддерживаю данное дополнение и не в курсе по поводу его текущей кодовой базы, все вопросы задавайте в поддержку modstore
Pavel Zarubin
23 января 2023, 15:37
0
Добрый день, я уже больше двух лет не поддерживаю данное дополнение и не в курсе по поводу его текущей кодовой базы, все вопросы задавайте в поддержку modstore
Pavel Zarubin
22 декабря 2022, 16:29
+1
ну для меня будет)
Достаточно просто загуглить «php framework banchmarks»
тык
Исходя из этого бенчмарка Lucinda быстрее laravel в 47 раз

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

ну это искусственный тест, а на реальных проектах заметно?
Конечно еще сильнее становится заметно чем обычный hello world, чем больше связей, чем больше данных тем более заметно, но это все не критично, laravel — идеальный php фреймворк, его выбирают за простоту работы, за то, насколько просто найти разработчика на него и насколько быстро можно реализовывать фичи, если недостаточно laravel'я, то стоит задуматься не о других фреймворках, а о других ЯП уже
Pavel Zarubin
22 декабря 2022, 15:33
0
а на slave
А как slave должен ускорить?
еще и кешированием
Оооо… тут вообще можно бесконечно рассуждать, говоря о кешировании, вы как, батенька кешируете? Например если ты кешируешь в файловую систему, то, забрать из fs будет сильно дороже по ресурсам и времени, нежели забрать из БД с правильными индексами. По другому обстоят дела если это memcached или redis, но тут будут и другие подводные камни, мы же говорим о базовой реализации, не так ли?
Pavel Zarubin
22 декабря 2022, 15:09
0
Вообще, думаю не будет ни для кого откровением, что laravel — один из самых медленных php фреймворков, он ориентируется не на скорость, он ориентируется на пользователей и простоту использования и ради этого жертвует скоростью
Pavel Zarubin
22 декабря 2022, 15:03
0
На тот момент, когда я ушел в laravel (это была еще 6.х версия) modx показывал на голой странице с выборкой из бд 1000 элементов гораздо меньше потребления и по памяти и по CPU, как сейчас дела обстоят не знаю, но подозреваю что +- также, да это и не удивительно, laravel из коробки содержит логики в несколько раз больше, чем modx, да и PSR ООП само по себе тяжелее, нежели легаси modx
Та же eloquent содержит в себе сильно больше логики и обвязки (потому что хочет быть похожей на ORM, но ей не является) чем пусть и кривоватый, но конструктор запросов под названием pdoTools
Pavel Zarubin
22 декабря 2022, 14:38
0
профит скорее всего есть
Хотелось бы услышать, какой?
Боюсь что он будет даже отрицательный, нежели положительный
Не меняя подход к выборке (например параллельные запросы), не меняя архитектуру базы данных, не проставляя индексы какое время вы хотите выиграть? А прослойка в виде api скорее всего только тормозит результаты
Pavel Zarubin
22 декабря 2022, 10:08
+3
Странное решение честно говоря
1) Зачем тут использовать laravel? Какие он преимущества даст, кроме собственного удовлетворения что теперь то «все красиво»
2) В быстрой фильтрации важнее правильные индексы и в принципе архитектура бд, laravel на это никак не повлияет
3) «Микросервисы» на PHP сложно назвать микросевисами, хотя бы потому, что они обмениваются по json api (вместо gRPC например) который медленный и сильно нагружает сеть, я уже молчу о том, что сам laravel сильно тяжелее того же modx

По мне лучше бы показал как интегрировать какой нибудь легковесный полнотекстовой поиск, по типу meilisearch и на основе него уже построить фильтрацию, а уже что там будешь использовать для обращения к api meilisearch laravel, modx или нативный php уже не важно
Так хотя бы профит будет
Pavel Zarubin
23 ноября 2022, 17:04
+1
Судя по всему так и есть, решилось бы выносом процесса скриншота в отдельный поток, и дальнейшую обработку «статусов обработки» но это уже немного выходит за рамки эксперемента на один вечер) Но за тестирование спаисбо)
Pavel Zarubin
22 ноября 2022, 20:22
+1
Круто! Но SVG похоже не хавает)
Да не было задачи сделать работающую на 100% штуку, была задача сделать штуку, с которой не справится php) На весь эксперемент был всего лишь один вечер)

Puppeteer
Очень много работал с пуппетером и его аналогами в ноде, go в этом плане сильно удобнее т.к. может группировать процессы на отдельные потоки, может например запустить браузер и держать его запущенным а каждую вкладку обрабатывать отдельным потоком, убивается поток — убивается вкладка и никаких memory leak
Pavel Zarubin
06 июня 2022, 03:07
0
modx.pro/components/19348 я хз насколько он сейчас рабочий но с десяток сайтов я им правил
Pavel Zarubin
26 февраля 2022, 16:11
0
Нет, обычный полнотекстовой поиск, там не такие товары и не такой заказчик чтобы заморачиваться с фильтрами и фасетным поиском) Наверное первый, кто дойдет до задачи фасетного поиска на этом проекте, просто перетащит его на какой нибудь условный ларавель, чтобы не иметь в будущем проблем)))
Pavel Zarubin
25 февраля 2022, 20:11
0
Все стандартно, кроме прикрученного эластика для поиска все нормально справляется если к этому вопрос )
Pavel Zarubin
24 февраля 2022, 19:16
0
примерно так будет.
Ну вот об этом я и говорю, какой смысл использовать тогда newQuery если все то же самое и в таком же количестве можно написать напрямую в SQL?

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

когда стоило последний сравнивать с более подходящим конкурентом – newQuery.
Не знаю, я все таки считаю что сравнивать с newQuery не корректно, newQuery просто транслирует php команды в SQL код, он не автоматизирует ничего и не упрощает
Pavel Zarubin
24 февраля 2022, 17:57
0
Я ж и попросил показать код на newQuery, мне не очень понятно зачем я должен его использовать, если я могу написать то же самое по объему и сложности на обычном SQL
Pavel Zarubin
24 февраля 2022, 17:55
0
Очевидно что не будет, а еще она также будет минимальна если все эти лефт джоины прописать руками в mysql, только вот newQuery так себе билдер
И код на newQuery будет скорее всего похож по количеству и структуре на выходной SQL
почему сравнивается getCollection, а не с newQuery
Потому что в случае с getCollection не надо джойнить tv, а можно их получить через getTVValue через модель собственно
Pavel Zarubin
24 февраля 2022, 17:20
0
Я честно говоря уже настолько долго не работал с modx что понятия не имею что за newQuery, если есть возможность и время, я был бы рад увидеть пример подобного запроса на newQuery, если там надо руками джойнить таблицы с тв, то какой в нем смысл по сравнению с написанием обычного SQL?
Главная причина почему пришлось писать билдер, это адская структура таблиц тв полей и сложность джоина каждого из параметров
Pavel Zarubin
16 апреля 2021, 17:20
0
Проверьте сейчас или минут через 15, должно появится, дополнение давно не проверялось, было бы неплохо чтобы вы еще и отписались работает ли оно вообще
Pavel Zarubin
07 апреля 2021, 13:14
+1
Да, только вот не смотря на не малое количество проектов, не смотря на гораздо большее количество разработчиков, чем в modx, и особенно их уровень, никто тянуть ее не стал
Pavel Zarubin
07 апреля 2021, 13:09
0
Когда то также думали про Yii, фреймворки умирают быстрее CMS и им проще это сделать