Оптимизация скриптов для снижения нагрузки на серверTimeweb.ru тарифного плана Eterno[B] вызвала разрыв пространственно-временного континуума..

Я видел похожее изменение по базе данных, когда хостер поставить MariaDB или PerconaDB. Нагрузка падала с 80% по всем до 15-25%. Не верится, что они столь оптмальнее, но.... Для пользователя эти продукты выглядят как обычный MySQL. 

Сергей, так как времени на то чтобы найти проблему хостер дает всего 5 дней то мы решаем задачу методом исключения по следующему алгоритму:

1. сначала отключаем все что только возможно отключить:
модуль "Веб-аналитики",
Документооборот,
Обмен с 1С,
возможность сбрасывать кэш (вдруг кто-то его сбрасывает?)
весь некритичный для работы сайта функционал
+ выставляем очень большое время кэширование.
задача — любой ценой снизить нагрузку на сервер чтобы войти в отведенные лимиты и удержаться на имеющемся тарифном плане

2. когда угрозы вылетить с тарифа уже нет — по очереди, с шагом в одни сутки (чтобы видеть как включение функционала сказалось на графике нагрузки хостера) включаем то что ранее отключили.


Сложность при такой диагностики добавляют несколько моментов:

1. хостер часто не считает нужным придерживаться рекомендациям Битрикс, например eAccelerator включили только недавно (теперь, чтобы понять как он влиял его бы в заданный час отключить..) и то не до конца:

Битрикс:


Таймвеб:


2. Немного дискредитировал себя график нагрузки от хостера, в результате уже нет к нему полного доверия — например на приведенном мною скриншоте три пятых числа, как его воспринимать серьезно?

3. Плавающая посещаемость ресурса также усложняет оценку того как сказались на нагрузке внесенные в функционал сайта изменения.


Сейчас, мы находимся на этапе №2, когда отключили все что можно + хостер полувключил eAccelerator. По этому что именно привело к снижению нагрузки выявим чуть позже.

А дело движется.
Проблема высокой нагрузки оказалась в стандартном компоненте bitrix:catalog.section, который во время фильтрации, при некотором стечении обстоятельств давал огромную нагрузку на сервер. Пообещали выпустить решение в обновлении, а мы получили заплатку.

Рекомендацию в мониторе производительности также скорректировали:

Роман ,добрый день.Столкнулся с той же проблемой, не могли бы Вы уточнить что конкретно битрикс посоветовал Вам сделать с catalog.section? Ну или поделиться заплаткой, ато уже оптимизировать код дальше некуда, а нагрузка на бд всеравно высоковата. Заранее благодарю.

Очень интересный вопрос, поделитесь пож-та решением

Отличный пост! По Акселлератору получал такой же ответ, но, тк было не критично - забил.

Методика снижения нагрузки хороша, если есть время. Большую часть проблем можно отловить и быстрее, используя отладку производительности. Не думаю, что вы его не использовали, но неужели этот модуль не отловил проблему с bitrix:catalog.section ?

И да, расскажите, в чем засада была, а то в каждом вашем посте - интрига

Кстати, это пост не фига не шуточный -- это нервное. Он трагичный по сути.

Знали бы вы ЧТО нам пришлось пережить в декабре с этим и с другими клиентами...

а по итогу, в данном случае, виноваты были (хотя это и не конструктивно искать виноватых, зато конструктивно делать выводы и улавливать общие тенденции):

1. таймвеб, который не включил eAcellerator  на специализированном тарифе под 1С-Битрикс..
2. и сам 1С-Битрикс (!) у которого была ошибка в компоненте bitrix:catalog.section +неверная рекомендация в мониторе производительности.

и чего стоило нам обычному партнеру защитить себя и свою репутацию перед клиентом? Кто мы и кто Таймвеб и 1С-Битрикс?

+писать что-то в ТП последних -- тот еще АД (тема отдельного разговора.)

Вот по этому некоторые и заводят СВОИ сервера и пишут СВОИ cms. Если тебя клиенты обвиняют в чем-то, то лучше знать что ты действительно виноват и решать проблему в своих серверах и в своей cms -- шансов больше, чем биться лбом в бетонную стену чужих ТП...
Ну еще вариант молча править косяки хостера и cms... (самый наверное конструктивный, но отвратительный по своей сути)

Расскажу подробнее какая ситуация вызывала нагрузку. В каталоге есть несколько свойств "Список" множественных. При фильтрации по значениям этих свойств в разделах, которые содержат подразделы(при использовании INCLUDE_SUBSECTIONS) стандартный компонент catalog.section очень долго производил выборку. В некоторых разделах SQL запрос обрабатывался до 50 секунд.

Вот какое решение предложили в ТП:


Проблема решилась, но обновления компонента потеряли.

Андрей, техподдержка что-нибудь говорит про сроки выхода обновлений с решением этой проблемы?
P.S. Спасибо за освещение этой проблемы)

По срокам к сожалению не говорят... Пообещали только, что вынесут в настройки компонента.