2.4.Бизнес-процесс решения проблем по ключевым операциям

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

1. Получить список жалоб.
2. По списку жалоб составить список ключевых операций (ограниченное количество).
3. По списку ключевых операций совместно с заказчиком назначить целевое время и приоритеты.
4. Пока идет согласование по п. 3 (это не всегда быстро), можно подключить и настроить ЦУП, но он не понадобится до этапа 8.
5. По списку ключевых операций встроить замеры в базу, получить результаты.
6. Сравнить результаты с целевым временем. Операции с плохим фактическим временем относительно целевого (с плохим APDEX) следует начинать разбирать в порядке убывания приоритета.
7. По каждой операции найти наиболее типичное действие (по гистограмме найти интервал времени, в который попало наибольшее количество замеров).
8. Для этого действия провести анализ, выяснить, что это за действие (как – описано в этом разделе ниже).
9. Понять, с какой проблемой имеем дело, что придется делать, и оценить трудоемкость решения.
10. Оформить результаты по п. 7 и 8 в виде отчета, согласовать с заказчиком дальнейшие действия.
11. Воплотить рекомендации в жизнь, сравнить результаты с целевым временем.

Теперь более подробно рассмотрим алгоритм анализа (п. 7, 8) и оценки трудоемкости (п. 9) из списка выше.

Рис. 2.4.1. Схема бизнес-процесса решения проблем по ключевым операциям

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

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

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

Выполнив именно это действие (например, проведя этот же документ) в тех же самых условиях, под тем же самым пользователем, но в нерабочее время, и сопоставив время выполнения этого действия с исходным временем, мы сразу сможем установить: происходили ли при выполнении этого же действия в рабочее время ожидания в очередях. Если они были, то время выполнения в нерабочее время будет гораздо меньше, чем в рабочее, и мы имеем дело с проблемой параллельности. Если же время выполнения осталось примерно то же самое, то мы имеем дело с проблемой производительности.

Чтобы было понятнее, можно вернуться к аналогии с автомобилем и гипермаркетом. Едем на той же машине в тот же магазин, но ночью. Если приехали намного быстрее, чем днем, то днем была пробка, следовательно, нужно устранять ее причины (строить развязку). Если приехали примерно за то же время, то мы ездим на «запорожце» – нужно менять его на «порше».

Определив, с какой проблемой имеем дело, можно четко установить план дальнейших действий. Сначала рассмотрим, что делать с проблемой производительности.

У проблем производительности есть два обычных подозреваемых:

• плохая работа запроса,
• плохая работа кода.

Прочие подозреваемые описаны в главе «Методики», разделы –. Методики их поимки, см., например, «Инструкции», раздел и «Методики», раздел .

Обоих обычных подозреваемых надо проверить.

Плохая работа запроса для СУБД MS SQL проверяется так: включив профайлер SQL Server, выполняем ключевую операцию еще раз и собираем длительности всех запросов, выполнявшихся во время его работы (показатель duration). Инструкцию, как это сделать и как получить их сумму, см. в главе «Инструкции», раздел . Если сумма duration близка ко времени выполнения всей операции, можно однозначно делать вывод, что потери времени происходят в СУБД. Дальнейшее исправление состоит в определении неоптимальностей и их устранении (см., например, главу «Инструкции» раздел ). Для измерения длительности запроса в других СУБД (не MS SQL Server) рекомендуется использовать технологический журнал «1С».

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

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

Второе, на что надо смотреть, есть ли строки кода, выполнение которых заняло существенную часть от общего времени. Это позволяет оценить шансы в борьбе за повышение производительности. Если такие строки есть, то шансы можно оценивать как очень хорошие. Если же таких строк нет и, например, на первом месте находится строка, выполнение которой занимает 3–5 % от общего времени, то понятно, что уменьшение времени выполнения этой строки даже до нуля даст прирост в те же самые 3–5 %. Поскольку речь может идти о том, чтобы ускорить выполнение операций в разы, шансы на это будут совершенно призрачны.

Далее надо оценить и согласовать трудозатраты, требующиеся на решение проблемы.

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

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

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

Обычные подозреваемые:

• избыточная блокировка данных в «1С» или в СУБД. Подробности по блокировкам см. в главе «Теория», разделы –;
• не справляется оборудование. Как организовать замер загрузки оборудования и интерпретировать значения, см. в главе «Инструкции», раздел .

Может, однако, случиться и такое, что сработает критическая секция (участок кода, который одновременно может выполняться только в одном месте), например:

• автонумератор,
• драйвер HASP-ключа и др.

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

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

Во всех этих случаях обращение в ЦКТП является правильным и может обеспечить успех проекта, а иногда и просто его спасти.

Отправить