2.2.Как измерять, как получать цифры

Как отмечалось в предыдущем разделе, работы по оптимизации производительности или повышению технологического качества работы системы могут быть инициированы:

• на работающей системе;
• на перспективной системе, к которой можно отнести как проектируемую систему, так и существующую систему, для которой запланированы изменения.

В обоих случаях методика замеров одинакова. Замерять надо:

• время выполнения ключевых операций с указанием, что за операция выполнялась;
• количество критичных ошибок в разрезе того, что это за ошибки:

- ошибки блокировок;

- системные ошибки;

- ошибки защиты;

- падение кластера серверов «1С:Предприятия»;

- зависание кластера серверов «1С:Предприятия».

Удобным способом получения длительности выполнения ключевых операций и их интегральных оценок по шкале APDEX является встраивание подсистемы «Оценка производительности» из состава Библиотеки стандартных подсистем «1С». Как ее встроить, см. главу «Инструкции», раздел .

Ошибки блокировок, системные ошибки и ошибки защиты можно считать по технологическому журналу. Как организовать сбор технологического журнала и его анализ, см. главу «Инструкции», разделы и . Этот алгоритм планируется встраивать в Центр контроля качества (ЦКК).

Аварийные завершения процессов кластера серверов «1С:Предприятия» можно считать по дампам, образующимся при падении процессов при включенной специальной настройке. Общий подход – см. главу «Инструкции», раздел . Рекомендуется, однако, использовать ЦКК, в него уже встроены подсчет дампов и их группировка по офсетам.

Зависание кластера серверов «1С:Предприятия» нужно отслеживать с помощью ЦКК. Вручную факт зависания можно отследить только непосредственно наблюдая его симптомы (процессы кластера находятся в памяти, но ни на какие запросы пользователей кластер не отвечает и новые клиентские соединения создавать не дает). Понятно, что такой метод ни полноты картины, ни удобства не обеспечивает.

Если речь идет о комплексе с одной базой, то всю собранную статистику можно объединять вручную. Однако если речь идет о комплексе с большим количеством баз и с интенсивным потоком событий, ручное формирование сводной статистики может превратиться в трудоемкую операцию, и в таком случае существенное облегчение может быть получено за счет использования ЦКК для автоматизации сбора всей статистики. О принципах работы ЦКК см. главу «Инструкции», разделы и .

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

О том, как организуются нагрузочные тесты, см. главу «Инструкции», раздел .

Для получения статистики перспективной системы применяется тот же состав замеров и методика их организации, что и для работающей системы. При этом надо понимать, что если нагрузочный тест не проведен заранее силами роботов, то это же нагрузочное тестирование все равно пойдет в первые же дни эксплуатации созданной (или измененной) системы. Только это тестирование пойдет уже на живых пользователях в ходе реальной работы, и еще неизвестно, какое из тестирований по факту обойдется дороже. Если все же принято решение о нагрузочном тестировании на людях, это также не меняет ни состава, ни методики организации замеров.

Данные, полученные в ходе измерений, как показатели APDEX, так и количество критичных ошибок, надо сравнить с целевыми требованиями и переходить к решению проблем.

По падениям и непонятным ошибкам, оцененным как критичные, необходимо обращаться в фирму «1С»: либо в техподдержку, либо через участие в проекте ЦКТП.

По задачам оптимизации ключевых операций последовательность действий определяется как движение по «незеленым» строчкам в списке полученных показателей APDEX, начиная с операции, имеющей наивысший приоритет.

Отправить