• История создания
• Сервер приложений 1С
  • Маркер "СП обход строк ТЗ"
  • Маркер "СП сериализация XML"
• Сервер СУБД
  • Маркер "СУБД выборка бухгалтерских проводок"
  • Маркер "СУБД неоптимальный запрос"
• Примеры выявленных проблем
  • "Магнит": переход на новую версию платформы
  • "Sunlight": апгрейд продуктивных серверов
  • "Тантор Лабс": сравниваем сервера приложений
  • "Тантор Лабс": опять сетевая проблема?
  • А что же маркеры СУБД?
• Как встроить обработку в вашу систему
• Идея для развития
• Заключение

История создания

Когда-то давно, когда я готовился к экзамену 1С эксперт, то в одном известном курсе услышал от преподавателя идею про эталонную ключевую операцию-маркер, которая выполняет каждую минуту какое-то простое действие типа проведения одного и того же документа или выполнения отчета. Затем смотрим как менялся показатель этой эталонной операции в течение дня, и соотносим с периодами замедления, если они были в вашей системе. Если периоды замедления были, то смотрим на счетчики оборудования, не было ли это "узким местом". Если нет, то тогда уже нужно искать дальше, что же является причинами деградации системы, оптимизируем и в итоге мы должны прийти к тому, что наша эталонная операция-маркер должна стабильно выполняться одно и тоже время в течении дня.

Я записал эту идею в свой конспект, который вел при просмотре курса.

Спустя время, не помню точно при каких обстоятельствах: то ли при просмотре конспекта, то ли из-за возникновения какой-то проблемы, я вернулся к этой идее и решил ее реализовать.

На тот момент у нас был реализован мониторинг ключевых операций по методике APDEX следующим образом:

1. мы разрабатывали корпоративную информационную систему, зоны ответственности которой были поделены между командами, например, команда № 1 отвечала за блок централизованных оплат, команда № 2 за товародвижение и тд.
2. за каждой командой был закреплен свой профиль ключевых операций, в которым были собраны только критичные для бизнеса операции. Если APDEX достигал заданного уровня (плохо и ниже) и удерживался на нем n периодов подряд, то срабатывал алерт.

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

Для каждого из этих серверов было решено написать по 2 маркера таким образом, чтобы они оценивали различные характеристики сервера.

Сервер приложений 1С

Для сервера приложений 1С было решено замерять выполнение арифметической операции в цикле и сериализацию.

Маркер "СП обход строк ТЗ"

В данном маркере выполнялось 2 действия на стороне сервера приложений:

1. Выгрузка результата запроса в таблицу значений (250 тысяч записей) — задействуем оперативную память сервера приложений.
2. Циклический обход таблицы значений с осуществлением операции присвоения значения.

По сути это чем-то похоже на то как вычисляется доступная производительность для каждого из рабочих процессов кластера 1С, только более наглядно, т.к. мы знаем какой конкретно код выполняется:

Запрос = Новый Запрос(
    "ВЫБРАТЬ ПЕРВЫЕ 250000
    |   АвансовыйОтчетТабличнаяЧастьДокумента.Ссылка КАК Ссылка,
    |   АвансовыйОтчетТабличнаяЧастьДокумента.НомерСтроки КАК НомерСтроки,
    |   АвансовыйОтчетТабличнаяЧастьДокумента.Сумма КАК Сумма,
    |   АвансовыйОтчетТабличнаяЧастьДокумента.СтавкаНДС КАК СтавкаНДС,
    |   АвансовыйОтчетТабличнаяЧастьДокумента.СуммаНДС КАК СуммаНДС
    |ИЗ
    |   Документ.АвансовыйОтчет.ТабличнаяЧастьДокумента КАК АвансовыйОтчетТабличнаяЧастьДокумента");
    Результат = Запрос.Выполнить();
     
    КлючеваяОперация = "СП_ОбходСтрокТЗ";
    НачалоЗамера = ОценкаПроизводительности.НачатьЗамерВремени();
     
    ТЗ = Результат.Выгрузить();
    Для каждого СтрокаТЗ Из ТЗ Цикл
        СтрокаТЗ.СуммаНДС = СтрокаТЗ.Сумма;
    КонецЦикла;
     
    ОценкаПроизводительности.ЗакончитьЗамерВремени(КлючеваяОперация, НачалоЗамера);