Обходные пути есть, но не на техническом уровне, а на организационном.
Например - уменьшить частоту обновления с 1С,
Насколько?
Зависит от скорости реализации в розничных точках. Определяется расчетно-эмпирически.
Тут вылезает проблема рассинхронизации остатков, но ее тоже можно решать организационно, опытным путем.
Дополнительно, если уж совсем картина скорости удручающа,
как-то кто-то упоминал здесь на форуме про “прогрев кэша”.
Не знаю что имелось в виду, есть подозрения, но не буду смущать своими догадками,
может, знающие пояснят, какие действия стоят за этим термином?
У меня например (еще с тех пор, когда модуль обмена был не настолько хорош, чтобы им пользоваться) была написана обработка в 1с и свой мод в my_changes, обработка его вызывает и передает файл с товарами, и мод разносит по базе количества, цены и некоторые характеристики (размеры для доставки, вес итп) - прямо в таблички. Но так как организационно в итоге расхождения стали возможны только в четырех случаях (новая поставка, изменение цен, возвраты, списание брака) - то и запуск обработки происходит уже давно не автоматически, а вручную при наступлении такой ситуации. Да и работает такой вариант гораздо быстрее.
Сложно перечислить. А если получится это грамотно описать, то это надо будет не на форум, а разработчику отправить для оценки, чтобы нормально переделали. Там просто уйма мест с “гениальными” решениями. Частично в следствии того что делалось итерационно, по частям, адекватными разработчиками, но не от в полной мере адекватного заказчика. Частично сам накостылил в коде. Есть и несколько коробочных багов и недоработок. Есть особенности самого сайта, не в полной мере соответствующие способу реализации и архитектуре выбранного решения. Есть наслоение из некоторого множества редко используемых модулей CS-Cart, не дружащих много с чем. Уйма всего, на самом деле. Но главным рукожопом во всём этом я считаю себя, пытаюсь потихоньку исправляться.
Это периодически поисковики устраивают. Как жахнут 300к страниц обхода за сутки - сразу становится интереснее, сидишь высматриваешь, что это сайт подтормаживает… Впрочем, греют и по чуть-чуть на регулярной основе. К слову, кстати, о кеше… они вот точно два раза одну страницу не открывают.
Основное что может в принципе убивать вам сайт это частые обмены с 1с, нужно настроить такой обмен в режиме обращения в случае изменений, либо же уменьшить такие запросы до более адекватного количества. Правильно коментировали выше что в случае изменеий в товрах происходит сброс кеширования, при большом количестве товаров это большой стрес для сайта, у некоторых клиентов разница в нагрузке на момент импорта увеличивается в десятки раз. Синтетические тесты которые вы проводили не являются корректными так как проходят в режиме когда не происходят изменения в системе, можно сказать только в режиме чтения. Множество клиентов падки на установку полностраничного кеширования, и это конечно в теории должно снять проблему, но кеш скрывает все проблемы которые возникают на сайте и в результате его наличие компенсируется медленными запросами к товарам у которых вышел ттл кеша, а если его ещё и скинуть то все успешно падает. Так же вы ограничиваете работу ряда динамических модулей, в общем вариант так себе и перечислять все возможные проблемы нету смысла. Конвертация в InnoDB действительно в ряде случаев улучшает производительность за счёт отсутсвия блокировок, но база более строго относится к наличию индексов, то есть да, можно, но аккуратно, так же InnoDB нуждается в более тонкой настройке, так же она подразумевает загрузку таблиц в оперативную память, нужно делать на это расчёт, все что не в оперативке будет работать медленее чем на MyISAM.
Предоставляем настроенные сервера, с нужными параметрами как железа так и софта. Все настроено, реализовано множество систем которые уменьшают нагрузку на сайт и ускоряют выдачу поисковикам https://zahid.host/ru/services/cscart/
Всем привет, хотелось бы подвести итоги, проделали кучу работ и тестов:
Увеличили ресурсы сервера в 2 раза - не помогло
Перенастраивали LEMP по разным рекомендациям - не помогло
Провели оптимизацию по размеру ресурсов (картинки, стили, скрипты и т.п.) - не помогло
Протестировали сайт на других VDS у других хостинг провайдеров - не помогло, у одного результат был чуть лучше, но незначительно.
Отчаявшись, методом исключения отключали модули и замеряли показатели GTMetrix - помогло
Подробнее о 5 пункте, дополнительных модулей довольно много, но на производительность влияют в нашем случае 3и, а именно: Google recaptcha, Google Marketing Tools и самописный для Callibri. Причём Google recaptcha и Google Marketing Tools вообще по жёсткому, Callibri по факту только подключает скрипт сервиса добавляет ID`шники для форм быстрого заказа и тормоза даёт именно внешний скрипт, но в сравнении с Google recaptcha и Google Marketing Tools не такие большие.
В общем если отключить все три, то показатели GTMetrix возрастают с E до B, TTFB c 1.2с до 686мс и полная загрузка с 10.1с до 2.6 Ну и визуально сайт начинает летать.
У кого нибудь есть идеи по данной проблеме? Что можно подкрутить?
