Большое кол-во витрин/поселений. Нужна оптимизация работы в админке.

Николай Иванов


У клиента перешли на работу с большим кол-вом поселений магазина внутри домена, по городам - domain.ru/moscow/*, domain.ru/omsk/* и т.д.
Всего около 1600 нас.пунктов. В принципе всё отлично, гораздо лучше чем работа через поддомены.
Но возникло одно но. Работа с заказами в админке. Открытие страницы заказов 10-15с, переключение между заказами те же 10с. Что при больших объемах сильно сказывается на скорости работы операторов и их нервных клетках. Сервер не при чём.

Грешил на "каналы продаж" и пр, но оказалось что "виноват" fronted_url, формируемый для товаров в заказе.
В админке, на странице заказов он не используется. Совсем. Однако массив продуктов формируется через общий shopProductCollection.

shopOrdersAction -> shopOrdersCollection -> getOrders() -> addPostprocessFields() -> shopProductsCollection -> workupProducts()
а там $p['frontend_url'] = wa()->getRouteUrl('shop/frontend/product', $route_params);

getRouteUrl -> getUrl, потом в цикле, для всех доменов и вложенном цикле для всех маршрутов этого домена идёт getAppRoutes и далее разбор всего этого безобразия. Туда я уже лезть не стал. Тормоза именно в этом месте - getAppRoutes и рядом.

Свою задачу - ускорить работу с заказами в админке, я сделал напрямую в коде, так как других вариантов нет.
Через использование доп.настройки в wa-config/apps/shop/config.php
'no_frontend_url_in_orders' => true

И исправления в shopProductsCollection -> workupProducts()

if ( !$this->is_frontend && $config->getOption('no_frontend_url_in_orders') && wa()->getRequest()->get('module') == "orders"){
    $p['frontend_url'] = false;
} else {
    $p['frontend_url'] = wa()->getRouteUrl('shop/frontend/product', $route_params);
}

То биш только для бэкенда, только для страницы заказов и наличии этой настройки не формировать frontend_url у товаров. Заказы летают, всё ок.
Но что делать дальше? Ведь это же до первого обновления. Хотелось бы видеть такой или любой другой костыль "в коробке", чтобы была возможность хотя бы в "ручном" режиме обходить эти тормоза и больше об этом не думать.
В идеале, переделать getUrl(только чур не я - там без ящика водки делать нечего, а я столько не выпью.), ведь я далеко не уверен, что не появятся плагины, которые будет использует frontend_url на странице заказа.

В общем просьба рассмотреть возможность оптимизации и/или сделать что-то -)
Оставляю в режиме обсуждения. Так как вроде и не ошибка, да и на пулреквест тоже не тянет.

15 мая 2018
  • J. B. diGriz 16 мая 2018 13:00

    По идее этого формирования списка URL вообще не должно быть. Не, конечно удобно за один запрос все получить, но было бы логичнее отдельный метод какого-то хелпера (обращающегося к роутеру).

  • Enso studio 16 мая 2018 13:53

    В своем проекте Вы можете заменить базовый класс приложения т.е. добавить в wa-config/SystemConfig.class.php что-то вроде

    waAutoload::getInstance()->add('xxx', 'wa-config/xxx.class.php');

    или сразу загрузить через require_once.

    Такой вариант не слетит при обновлении, минусы такого подхода думаю ясны, но других вариантов не вижу.

  • Николай Иванов 16 мая 2018 14:53

    В своем проекте Вы можете заменить базовый класс приложения т.е. добавить в wa-config/SystemConfig.class.php что-то вроде

    Это замечательно, что я могу это сделать. Но это не отменяет ручной просмотр изменений при выходе каждой обновы. Ведь класс коллекции один из основных и используется повсеместно. Что по понятным причинам хочется избежать.

  • Николай Иванов 16 мая 2018 14:57

    К тому же речь идёт вообще об оптимизации.
    Ведь getUrl используется везде. Например та же кнопка "открыть витрину" в админке - она при каждом обновлении вызывает эту штуку. Вот чтоб её не кэшировать для каждой витрины хотя бы?
    При любом, мало-мальски большом кол-ве доменов или поселений возникают дикие неудобства из-за километровых списков этих урлов. Про тормоза я уже сказал.

  • Enso studio 16 мая 2018 16:12
    минусы такого подхода думаю ясны
    Но это не отменяет ручной просмотр изменений при выходе каждой обновы.

    В любом случае придется следить за обновлениями даже если бы класс наследовался или использовались хуки т.к.

    Сама реализация роутинга ущербна и не идет ни в какое сравнение с нормальными фреймворками, например, при естественном/смешанном типе ссылок создаются роуты для всех категорий магазина, в kohana, роут может иметь callback что позволяет избежать таких нагрузок на ram.

    Webasyst имеет плохо структурированный и оптимизированный код т.ч. я бы не рекомендовал подобные проекты на нем, требуется полный рефакторинг кода на что WA не пойдут - у них просто нет специалистов такого уровня + основной % пользователей не использует витрины.

  • J. B. diGriz 17 мая 2018 00:38


    В своем проекте Вы можете заменить базовый класс приложения т.е. добавить в wa-config/SystemConfig.class.php что-то вроде

    Вполне достаточно положить переписанный класс в /wa-apps/shop/lib/custom и оно будет грузиться вместо штатного такого же. И не будет затираться обновлениями.

  • Enso studio 17 мая 2018 02:56

    @J. B. diGriz не встречал такого решения, спасибо - запомню.

    Посмотрел и проверил код waAppConfig - все верно.



Чтобы добавить комментарий, зарегистрируйтесь или войдите