Какие необходимы ресурсы или проблема всё таки в настройках?

В общем, есть сайт и сервер со следующими характеристиками:
VDS:
CPU - 4 core
RAM - 6 Gb
SSD NVME - 60 Gb
Сайт:
CS-CART - 4.14.1
Шаблон - YOUPI от alexbranding
Товаров ~ 7000 шт.
Каждую минуту срабатывает обмен с 1С
Посетителей в сутки ~ 350
GTM, метркика яндекса и ещё пару тройку счётчиков подключены

Всё это работает на php7.2 + MYSQL + NGinx (опыт в настройке окружения имеется)
Opcache, imagemagick, конвертация таблиц в InnoDB и прочие рекомендации выполнены (опыт тоже есть)

Технические тесты (из консоли) показывают стабильные показатели, а вот визуально и в отладчике браузера всё неоднозначно. По честному заметно, что скорость работы не молниеносная как хотелось бы.
Есть ли у кого возможность показать пример свои конфиги (NGINX + PHP + MYSQL)?
Или всё таки сервер слабоват?

Подскажите, что за технические тесты использовали? Интересно узнать.
Я добавлял в формат логов Nginx переменные $request_time и $upstream_response_time. По ним можно определить время обработки запросов.

Вы измеряли время ответа при MyISAM и InnoDB? Эта рекомендация выглядит сомнительной, т.к. обычно запросов SELECT сильно больше, а с ними вроде как лучше MyISAM справляется.

curl -s -w ‘Testing Website Response Time for :%{url_effective}\n\nLookup
Time:\t\t%{time_namelookup}\nConnect Time:\t\t%{time_connect}\nAppCon
Time:\t\t%{time_appconnect}\nRedirect Time:\t\t%{time_redirect}\nPre-transfer
Time:\t%{time_pretransfer}\nStart-transfer Time:\t%{time_starttransfer}\n\nTotal
Time:\t\t%{time_total}\n’ -o /dev/null <доменное имя>

Измерял, после конвертации в InnoDB показатели лучше!

Есть физические точки продаж? Не совсем понятна нужда обмена с 1С раз в минуту.

2 лайка

Поддерживаю
Сам обмен, сколько времени занимает? Неужели меньше 1 секунды? Если больше - то у вас процесс на процесс должен накладываться: предыдущий еще не завершился, а уже следующий на запуске.

Я бы ещё добавил что это убивает большую часть кеша и делает его работу малоэффективной.

1 лайк

У вас на сайте нет кеширования, совсем.

Увы, с кешированием CS-Cart вообще что-то стоило бы сотворить. Практически любое изменение товара его сбрасывает. Следовательно, если сайт живой, над ним постоянно работают контент-менеджеры, обновляют товары, цены и остатки - даже если товар конкретный затронут не был, его кеш сбрасывается. Следовательно, если товаров много, а трафик заметно меньше чем число посетителей, вероятность попасть на кешированную страницу намного ниже чем на не кешированную.

Да, есть физические точки продаж.

Почему? Можете подробнее объяснить?

Расскажите, почему?

Была проблема с 1С накладывались процессы. Пофиксили!
Нет не меньше секунды. Если не в курсе, 1С изначально Первы запросом кладёт архив с файлами. Вторым запросом распаковку запускает. Третьим подготавливаются файлы импорта (идёт проверка на актуальность переданного файла). Четвёртым запросом начинается обработка (1С ждёт ответ). Пятым запросом, забирает (XML) данные о заказах.
Движение товаров не такое большое. Бывает файлов вообще нет. В 1 минуту вполне каждый обмен укладывается.

Кстати конвертация таблиц в InnoDB чуть скорость увеличила.

Каждое изменение таблицы products сбрасывает кеш со всех товаров. Если часто обновляются цены/остатки/выгружаются товары, даже на 1 товар - кеш сбрасывается со всех. Как следствие, если трафик 350 человек в сутки, а товаров 7000, то если хотя бы несколько раз в сутки обновлять какие-то товары, почти все посетители будут открывать страницы без кеша.

1 лайк

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

Грубое, но реалистичное. А с учетом современных требований многих систем и площадок(а для кого-то - поставщиков) - обновлять цены и остатки надо максимально часто. Товаров при этом много, посетителей не так много. Обновлять остатки надо часто, максимально часто. Карточки товаров изменять тоже. Как следствие, например, у меня контент-менеджеры обновляют в среднем за день 5-6 групп товаров, столько же делают выгрузок. Плюс в среднем 2 правки в день в товары в связи с выявленными ошибками. Плюс 4 обмена цен и остатков. В итоге самих товаров в сутки меняется/добавляется не более 100, при общем числе товаров 30000. Но из-за обновления цен и остатков, этих правок, кеш сбрасывается на все. Ярко выраженных звёзд среди товаров нет, трафик распределяется главным образом примерно на 6000 товаров, по-мелочи еще на 10000, оставшиеся 14000 практически мёртвый груз. Сколько нужно иметь трафика на сайте чтобы существующее кеширование работало с заметной эффективностью? Увы, посетителей в сутки обычно менее 6000. А кеш сбрасывается минимум 10 раз в день на все товары, причем большей частью именно днём(и разок ночью), в то же время, когда и посетители пользуются сайтом. Я вот не вижу ситуации, когда существующий механизм кеширования будет работать, при любых размерах сайта, кроме случаев когда сайт мёртв или продаёт исключительно редко меняющиеся цифровые товары. Сбрасывать кеш на всё при изменении одного товара - плохое решение.

Одно решение - делать так чтобы сайт более-менее работал вообще без кеша(увы, тут мне есть над чем поработать… работать то работает, но так себе, даже при наличии некоторого запаса по железу).
image

Какая жесть! Есть обходные пути?

Есть модули полностраничного кеширования. Мне мало что подходит т.к. сам накосячил и мне уже ничего не поможет без переписывания половины сайта.

Подскажите, пожалуйста, что именно вы сделали не так.

У нас вот обмен с МойСклад раз в полчаса примерно, плюс периодически менеджеры добавляют и обновляют товары.
Присматривались к модулю https://www.cs-commerce.ru/moduli/full-page-cache-addon-for-cs-cart-ru.html, по похожим на ваши причины, пока отказались.