А
ну можно дополнительно чекать момент изменений и перекэшировать данные...
Size: a a a
2021 July 02
D
ну я тоже думал на метод апдейта поставить внизу перекеширование заказа
MG
Если проблем с производительностью нет, то не целесообразно. Если есть, то можно начать или с уменьшения информации которая подтягивается, или с внедрения более частотной пагинации заказов. Если ничего не поможет, тогда уже рассматривать кеширование
M
хочется сделать один единственный контейнер с правильной конфигурацией всего, который джун развернёт на своём ноутбуке и сразу же, ничего не трогая, сможет работать над проектами.
в проде стоит та же конфигурация, только в виде нескольких контейнеров (веб и бд), но там alpine/openrc
от alpine, кстати, скоро наверное придётся уходить. musl напрягает.
в проде стоит та же конфигурация, только в виде нескольких контейнеров (веб и бд), но там alpine/openrc
от alpine, кстати, скоро наверное придётся уходить. musl напрягает.
D
сейчас сделал пагинацию, уменьшение информации, запрос на беке на один месяц (пагинация помесячно) обрабатывается 1.5 секунды
MG
Понял, спасибо. Так понимаю что джуны ещё и на винде?
D
для такого запроса 1.5 сек норм?
Я
Друзья, подскажите может есть красивый способ решения:
во вьюхе вывожу
Но может быть такое $messages=null, тогда ругается, что нет индекса 'message_1'
Можно сделать вот так:
Но, что-то не очень красиво получается. Есть другие варианты?
во вьюхе вывожу
@if(($messages['message_1'])) {{ $messages['message_1'] }} @else Нет оповещения @endif Но может быть такое $messages=null, тогда ругается, что нет индекса 'message_1'
Можно сделать вот так:
@if($message) @if(($messages['message_1'])) {{ $messages['message_1'] }} @else Нет оповещения @endif @endif Но, что-то не очень красиво получается. Есть другие варианты?
MG
А сколько попадает заказов в эту “помесячную” пагинацию?
M
да, но в общем-то без разницы. все те же контейнеры даже на raspberry pi будут работать без изменений
D
140 по факту на прошлый месяц
D
но и плюс около 6-7 связей тянется по каждому заказу, типа комментарии, заметки к заказу от пользователей, водители, диспечеры
D
ладно, похоже что кеширование не надо, с этим всем, 146 заказов отработали за time: 0.881 sec
я на php через microtime проверил
я на php через microtime проверил
ST
array_key_exists
MG
Как дополнительный вариант решения рассмотрите возможность создания помесячных view за полгода/год в базе данных, куда заранее вынесите самую базовую информацию. Сможете как минимум делать потом выборку только по конкретным id заказов и только по ним делать агрегацию дополнительной информации. Как по мне, по сложности это выглядит не сложнее чем кеширование с инвалидацией
D
Согласен, хороший вариант
Я
спасибо, но не помогло, сделал через isset
А
а какое количество строк обрабатывается?
и какой объем данных возвращается.
это 1 запрос тянет все, или 100500 разных мелких запросов?
база развернута на серваке или под виндой в опенсервере?
и какой объем данных возвращается.
это 1 запрос тянет все, или 100500 разных мелких запросов?
база развернута на серваке или под виндой в опенсервере?
D
1 запрос основной и в нем где-то 7 with и 2 мелких отдельных запроса
D
база mysql на этом же серваке