Каталог решений - Чрезмерная оптимизация кода. Проблемы производительности

Продолжаем серию статей по вопросам оптимизации производительности. В этот раз у нас один интересный случай, который по праву заслуживает пристального рассмотрения.

Оптимизация в данном примере возведена в абсолют абсурд, по моему скромному мнению. Давайте рассмотрим данный пример, который мне подкинул коллега разработчик. Скажем спасибо Светлане, она сделала мой день) возможно, и Ваш тоже.

Мы рассмотрим эту проблему в классическом подходе:

• Выявление проблемы
• Объяснение ситуации
• Поиск решения

I) Выявление проблемы.

Как было сказано выше, то с данной ситуацией столкнулся разработчик. Он выполнял перенос изменений из одной версии ERP 2.4 в новую 2.5. И при попытке проверить решение на рабочем примере увидел неожиданное поведение платформы — база зависала. Конечно же она работала, но выглядело это не очень обнадеживающе.

Давайте найдем точку возникновения проблемы. Примерная позиция нам известна, но как говорится точность позволяет повысить скорость решения проблемы. Открываем нашу конфигурацию мониторинга производительности и ищем долгие запросы. Этот запрос виден сразу, он один единственный длительностью более 6 тысяч секунд.

На рисунке мы видим, что во временную таблицу помещается почти 11 миллионов строк. Как мне рассказал разработчик, то таблица товаров в тестируемом документе содержала около 1000 строк. Обратите внимание, что специалисты нашей команды проверяют не на 2-3х строчках, а с достаточным количеством данных. Если бы мы тестировали тяп-ляп, то этой проблемы не обнаружили.

Ниже приведен контекст рассматриваемой ситуации.