4.15 - долгое открывание корзины по вине модуля СДЕК

Взялся опять за мои магазины на CS-Cart. Имею (версия, версия РНР, модули доставки)
(1) = 4.3.6, РНР 7.0, Почта + СДЕК. Модули из коробки. 20шт товаров, почти пустой.
(2) = 4.15.2, РНР 7.2, Почта + СДЕК. Стоит модуль полностраничного кеширования CSC. 3000шт товаров.
На одном и том же сервере.

(1) - БЕЗУМНО долгое открытие корзины или переход “оформить заказ”. Настолько долгое, что можно выкинуть магазин на помойку, покупатель не будет ждать. 15-20 (!!!) секунд. В то же самое время (2) - почти мгновенно, то есть при первом заходе после длительного простоя небольшая (порядка 2 сек) задержка, а потом - менее 0.5 сек (страницы сайта открываются за 300-400мс).

Отключаю СДЕК - становится почти как (2), небольшая задержка (но есть!). Отключаю Почту - летает.

ВОПРОС: может я забыл где кеширование какое включить? Что делать? Бессмысленно переходить на 4.15 (4.17?), это все равно, что закрыть магазин…

UPD: обновил до 4.17. Стало получше. РНР теперь 8.1 (вообще, 7.2 - какой-то странный кастрат у меня). В процессе обновления предупреждение - что были изменены вручную файлы. Причем из 5 штук я реально руками менял только ОДИН, так что это какой-то косяк инсталлятора.
НО! В списке - файлы модуля СДЕК. Ради интереса сравнил новые с архивными, и обнаружил - в новой версии отсутствует функция и хук ПЕРЕБОРА ВСЕХ ТОВАРОВ корзины, с целью определить вес. Если при этом каждый раз происходило обращение к СДЕКу, то вот оно где и жило.

ОДНАКО: разница все равно есть с (2) и очень заметная. Если (2) корзина открывается 3-4 секунды после простоя (кеш запроса с СДЕК???) и менее 0.5 повторно, то (1) всегда 2-3 секунды. Хотя тут я думаю уже может работать отсутствие модуля постраничного кеширования.

ВЫВОД: обновляйтесь с 4.15, там косяк.

Значит так, рассказываю. Виной тормозов - логика работы CS-Cart с модулем СДЕК + работа API самого СДЕК.

Посмотрел лог. Каждое открытие корзины, независимо от выбранного способа доставки, приводит к запросу:

Запросы (http/https запрос)
**URL:** https://integration.cdek.ru/pvzlist.php

Так как у СДЕКа дохренеллион ПВЗ в крупных городах, а у меня выбрана Москва, то ответ на этот вопрос и занимает 2-3 секунды (у меня на самописном движке я сам примал кодик, он как раз и показывает до 5 секунд время ответа).

Сменил ради интереса на Иваново - все, полетело. Открывается корзина почти как (2).

ВОПРОС: зачем каждый раз запрашивать СДЕК о списке ПВЗ? Почему это не сделать ТОЛЬКО при выборе способа доставки ПВЗ?

Потому-что так сделана интеграция :slight_smile: коробочные продукты чаще всего так и работают. Мы сейчас нашему клиенту этот момент переделали, мало того мы сделали забор пунктов по расписанию. Но пока не очень понятно, стоит ли этот оформлять в модуль, есть ли у кого еще такая проблема.

Тут скорее вопрос к самому сдэку. Им бы хорошо отдавать, были ли с определённого момента изменения в списке пвз. Тогда все было бы гораздо проще.

Нет, тут СДЕК винить нельзя. Хотя их можно во многом повинить… Им следует хранить время и ИД запроса прошлого? С чего бы это?

1 лайк

Нет, не им. Карт хранит в сессии, когда последний раз спрашивал список пвз. При следующем запросе передает эту дату. Сдэк смотрит дату своего последнего редактирования списка пвз. Если дата новее - говорит, что можно скачивать. Если нет - говорит что изменений не было. Карт заносит в сессию дату этого обращения, и теперь уже скачивает, а чаще всего нет - список пвз. Экономия по времени колоссальная, да и на сам сдэк нагрузка меньше.

Это ненужная для них сложность. Надо просто кешировать пункты + делать это по расписанию, но для коробки опять же это невыполнимо.

Зачем??? Не проще ли запрашивать ПВЗ только при выборе «самовывоз»? Сейчас же они запрашиваются вообще всегда.

Все хорошо, но у СДЕКа нет даты списка, по крайней мере - по API.
Да и обновляться он может ежечасно - поменялся режим работы ОДНОГО из 1000 и все.

4000 пунктов у СДЕК. Даже если раз в год меняется что-то у каждого - а параметров порядка 20 - то это 10 раз в сутки.

Нет, лучшее решение как раз со стороны ЦМС, не делать ненужный запрос.

У меня так сделано - идет запрос тарифа, он показывается юзеру. Если юзер выбирает ПВЗ, то только тогда идет запрос списка.

Так устроены коробки, чем проще реализация, тем более гарантированно заработает сразу без доп настроек - понимаю, что кажется странным, но это везде. А вот уже более тонкая работа - всегда модули или доработки.