Проблема Shop-Script или криво настроенный MySQL или ...?
Здравствуйте!
Хотел бы узнать у других пользователей Shop-Script - какой у них средний отклик сервера (например, по Метрике), а у специалистов по серверам - что можно сделать в указанном ниже случае, чтобы снизить средний отклик, который на данный момент составляет в среднем 450 мс по РФ и на ПК, и на смартфонах. Если по типам страниц, то главная - 360 мс, каталог - 430 мс, карточка - 490 мс. И вообще возможно ли это сделать на Webasyst низкий отклик или же придется смириться, пока Webasyst не внедрит аналог композитного сайта, как у Битрикса/исправит запросы/улучшит кэширование?!
Исходные данные:
Сервер: VPS на KVM с Xeon Gold 4x3.0 GHz, 8 GB DDR4, 50 GB SSD RAID10, порт 1000 Mbit.
Конфиг: Nginx (SSL, HTTP2, TLS 1.3, режутся вредные боты), PHP-FPM 7.3 (opcache, memcached), mysql 5.6 на InnoDB, в память не упирается. Размер БД всего 600 мб, 2000 товаров, посещаемость 1500 хостов в сутки, большинство трафика из Москвы, где расположен сервер и дата-центр, подключенный CDN.
По движку: последний Shop-Script 8, тема на основе MegaShop (тяжеловат, но не настолько, чтобы так сильно повышать отклик), везде кэширование, из "тяжелых" плагинов разве что SEO-фильтры (самих фильтров мало, на страницах мало просмотров), SEO-регионы - больше сотни витрин, но разницы не заметили, когда их было всего несколько - опять же, ботов режем, а скорость обхода в Вебмастере по каждому поддомену, кроме нескольких основных, вручную настроена на минимальные 0,6 запросов в секунду, для всех остальных, кроме Гугла, Crawl-Delay на 60 сек.
Что по итогу: мощная железка, достаточно свежий и быстрый сервер с улучшалками, малая база, низкая посещаемость, кэширование, вся статика через CDN, порезанные боты и краулер Яндекса, нагрузки на сервер не видно (скриншот https://i.imgur.com/fyTDz83.jpg) но... отклик почти 0,5 секунды. Что делать? На сервере есть еще несколько сайтов на совсем неоптимизированном WP почти пустые с околонулевым трафиком - 180 мс.
Больше всего беспокоит статистика MySQL, показатели работы за последние 20 дней:
Самое пугающее - огромные значения Handler read rnd (767,3 M), Handler read rnd next (17,1 G), Select full join (11,5 M). Если я правильно понимаю, то за 20 дней было 11,5 миллионов JOIN-запросов без индексов. Хотелось бы понять, это в самом движке всё так плохо или только у нас такая аномалия?
Mysqltuner молчит, советуя лишь выставить join_buffer_size > 2M, однако на Percona была статья, где объясняли, почему не стоит этого делать, и рекомендовали использовать дефолтное значение. Хотя всё же попробовал поднять выше 2M - ничего не поменялось, по ощущениям даже хуже стало. Скриншоты Mysqltuner:
Несмотря на подавляющее количество SELECT-запросов, используется InnoDB, поскольку уже везде и во все трубы кричат, что на мускуле 5.5+ MyISAM перестал давать преимущество даже в SELECT'ах. Пробовал сам MyISAM и тоже не заметил положительных изменений, вернулся обратно на InnoDB.
Основной конфиг MySQL:
tmp_table_size = 512M
max_heap_table_size = 512M
join_buffer_size = 2M
query_cache_size = 0
query_cache_type = 0
max-connect-errors = 100000
open_files_limit = 29696
table_open_cache = 16384
table_definition_cache = 16384
max_allowed_packet = 32M
interactive_timeout = 180
wait_timeout = 180
connect_timeout = 30
optimizer_search_depth = 0
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_file_size = 512M
innodb_stats_on_metadata = 0
innodb_open_files = 16384
innodb_io_capacity_max = 6000
innodb_io_capacity = 3000
innodb_read_io_threads = 64
innodb_write_io_threads = 16
Какие есть идеи?
Эта тема в архиве. Добавление комментариев к ней отключено.
13 ответов
Хороший топик. Подписался. Надеюсь, узнаю здесь полезную информацию.
---
Жду не дождусь от Webasyst рассылку, которая будет начинаться вот так:
"Мы выпустили большое обновление приложения Shop Script, в котором хорошенько поработали с производительностью и подготовили для вас инструкцию по оптимальной настройке сервера."
Пока что получаю только это :(
"Судя по пожелтевшей листве, новый сезон окончательно вступил в свои права! Пришла пора греть руки о чашку с горячим чаем, укутываться в плед по вечерам, радоваться отоплению в квартирах и писать тёплые письма своим родным, близким и… клиентам."
Укутался в плед, грею руки, радуюсь близким. Клиентам всё чаще и чаще радуются магазины на движках, где сайты работают пошустрее..
Ну не знаю, я нашел себе нормальное пристанище. Вот ответ самой жирной категории с кучей фильтров. Всегда онлайн 20 человек. Около 2000 тыс в сутки. У меня стоит шоп скрипт 7. Вообще ничего не оптимизировал, работает все как пушка.
но я не использую плагин сео регионы. На форуме часто писали, что 1 регион считай это отдельный сайт. 100 регионов, это уже наверное какой то дедик нужно брать в порядке
Помимо TTFB очень важно знать как отдается остальной контент. Если скажем первый байт прилетает конечному клиенту на 450 мс, а полная загрузка видимого контента завершена на 0.8-1 сек, то фактически это отличный результат. Если же при низкой задержке в 150 мс полная загрузка видимого контента страницы длится 4-5 сек, то это провал.
а как вам такое?) https://ibb.co/rZz2kKy и ничего висит в топе) люди ещё мучаются, стареют, но делают заказ спустя час))) Двиг мадженто, не шш
Похоже на webasyst или на какого-то нерадивого разработчика плагинов надвигается буря.
Примерно в похожей конфигурации с автором наблюдаем такую картину
Это нагрузка на базу данных на самом дорогом тарифе хостинга, которую пришлось увеличить до предела и похоже сегодня мы его тоже преодолеем. Дальше сайт будет заблокирован до начала следующих суток. Такой тариф прошу обратить внимание виртуального хостинга стоит 3990 р/мес.
Сначала думали, что мы так выросли, что пора на vds переходить. Выбрали сразу мощный тариф у давно известного хостера по характеристикам примерно как у автора и очень удивились, что сайт может так медленно работать, теперь быстро перешли на шаред и похоже здорово пожираем общие ресурсы, но можно более менее работать есть не читать постоянные предупреждения яндекса о долгой загрузке.
Предыдущий хостер не считал нагрузку на базу данных, но исправно от нас получал гневные письма о медленной работе сайта, а тут выяснилось такое чудо.
Пока думаем, что дело в плагинах. Выводов делать пока рано. Ищем зловреда
Без дополнительных данных из представленного графика ничего не понятно, кроме того, что проект вы запустили во второй половине дня 27/10. Хотя б сколько товаров скажите, и приблизительную посещаемость, чтоб можно было понять масштабы ваших страданий.
График показывает суммарную нагрузку на базу данных секунд одним ядром процессора.
Нашли зловреда.
Им оказался плагин гибкие скидки. Отключили все правила и полетели
В указанном плагине есть включение кеширования. Не пробовали сравнить нагрузку при включенном кешировании?
А сколько их было? А товаров сколько?
А у вас точно шаред-хостинг за 3990..?
кэширование было включено, но не помогло.
1300 товаров
10 правил скидок
Точно шаред за 3990 которого по нагрузке на базу данных не хватило.
Про ядро. Это таймвеб так считает нагрузку на базу данных.
https://timeweb.com/ru/services/bitrix/
Подключен тариф Eterno + пришлось докупать лимит на базу. Итого получилось 3990 р/мес.
Vds под такую нагрузку обойдется не меньше 10000 р/мес
Прожорливый оказался плагин
С отключенным плагином можно уложиться в тариф за 200-300 р
Возможно, проблема связана с каким-то определенным правилом скидок. Например, не стоит использовать проверку наличия товаров в определенном списке - так нагрузка гораздо выше, чем если использовать проверку характеристики товара. Ну итд.
Попробуйте выполнить Оптимизацию плагина и темы дизайна. После каждого пункта проверяйте скорость работы, чтобы понять, что именно помогло.