DeepEdit!

Технические специалисты иногда ограничивают свою область деятель­ности нижними уровнями технологического стека, на которых они чувствуют себя наиболее комфортно. Такое поведение повышает риск упустить возможности значительного повышения производительно­сти. В качестве примера приведу заказчика, с которым я работал в се­редине 1990-х. Бухгалтерия ежедневно выпускала трехфутовую стоп­ку отчетов о предварительном балансе главной книги (General Ledger (GL) Aged Trial Balance). Выяснив причины столь частого запуска это­го отчета, руководитель проекта внедрения главной книги из Oracle Consulting объяснил пользователям, как они могут получить нужные им данные менее затратным способом с помощью онлайновой формы. В результате мы смогли уменьшить нагрузку на систему на миллиар­ды команд в день, не затратив на «настройку» ни цента. Такое реше­ние не только разгрузило систему, но и облегчило работу пользовате­лей, которым гораздо удобнее работать с онлайновой формой, чем вы­лавливать нужные цифры из отчета толщиной в дюйм.

Сооснователь компании hotsos.com, Гэри Гудман (Gary Goodman), рас­сказывал о проектах внедрения приложений, которыми он руководил во время работы в Oracle Corporation. Один из приемов, практикуемых им в процессе внедрения, состоял в отключении всех прикладных от­четов в системе. Когда пользователи приходили с просьбой о недостаю­щем отчете, специалисты подключали его обратно. По опыту Гэри, ни разу не пришлось подключить больше 80% отчетов, первоначально имевшихся в системе. Как по-вашему, какие 20% из ваших отчетов пользователи никогда не читают?

На уровне бизнес-требований вашего технологического стека вопрос, на который вы должны ответить, звучит так:

Действительно ли все предъявляемые бизнес-требования оправданны?

Не оправданные интересами бизнеса пользовательские операции сле­дует просто отключить. В действительно необходимых пользователь­ских операциях постарайтесь исключить бесполезную работу (некото­рые способы рассмотрены в главе 11). Данные диагностики производи­тельности будут «подталкивать» вас в направлении снизу вверх, хотя, как правило, эффективнее продвигаться «сверху вниз». Например, прежде чем настраивать отчет, узнайте, нельзя ли от него отказаться. Не ограничивайте свою работу по оптимизации только техническими вопросами. Как было отмечено в главе 1, хороший аналитик по произ­водительности должен хорошо разбираться в том, как соотносятся ме­жду собой требования бизнеса и вычислительные мощности, призван­ные обеспечивать выполнение этих требований.

Наконец, не забывайте о том, что с точки зрения бизнеса пользователи не работают с системой, они являются ее частью. Иллюстрацией это­го может служить история, рассказанная моим коллегой Риком Мину-теллой (Rick Minutella). Компания пригласила его оптимизировать производительность модернизированного недавно приложения ввода заказов. В табл. 10.1 показана разница в производительности до и по­сле модернизации. На типичном «большом совещании» с участием фи­нансового директора, пользователей, руководителей IT-отделов и поставщиков оборудования компания потребовала от корпорации Oracle восстановить производительность формы ввода заказов, которая губи­ла весь бизнес.

Показатель	Значение	Значение после
производительности	до модернизации	модернизации
Скорость ввода заказов	10 вызовов/час	6 вызовов/час
Время отклика формы	5 сек/экран	60 сек/экран

Что и говорить, 60-секундное ожидание онлайновой формы ввода за­казов - это слишком долго. Однако утверждение «производительность формы ввода заказов губит наш бизнес» попросту неверно. И вот поче­му. Если бизнес работает со скоростью шесть телефонных вызовов в час, то средняя продолжительность вызова составляет десять минут. В примере 10.4 приведен профиль ресурсов для такого вызова при ра­боте с 60-секундной формой.

Какое максимальное влияние на бизнес может оказать оптимизация формы? Ответ приведен в примере 10.5. Если полностью исключить время отклика формы, общее время обработки заказа уменьшится только до девяти минут.

Total        540s 100.0%

Беда в том, что этого недостаточно. Если оператор сможет принимать один заказ в среднем за 9 минут, то за час он примет в среднем только 6,67 заказа. Это все еще довольно далеко от требования обработки 10 заказов в час. Само по себе повышение производительности формы ввода не поможет этой компании увеличить скорость ввода заказов до указанного значения. Бизнес «убивает» вовсе не форма, а то, чем за­нимаются принимающие заказ операторы в оставшиеся 9 минут.

Для того чтобы улучшить производительность в данном случае, требу­ется выйти за рамки обычной «настройки системы». Куда же пропада­ет это «оставшееся» (other) время? Среди прочих возможностей выде­лим такие:

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

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

Еще одно интересное предположение, которое следует проверить, - не группируются ли звонки по времени таким образом, что клиенты тра­тят много времени на ожидание ответа в часы наибольшей занятости. Уроки теории массового обслуживания, данные в главе 9, помогут вам более эффективно справиться с наплывом звонков, либо задействовав дополнительных операторов, либо уменьшая время обслуживания клиента. Здесь есть, о чем подумать. Главное - не ограничиваться при рассмотрении своей «системы» лишь характеристиками программно­го и аппаратного обеспечения. Бизнес требует, чтобы «систему ввода заказов» рассматривали шире, учитывая, что все участники процесса размещения заказа оказывают влияние на прибыль, возврат инвести­ций и приток денежных средств.

Устранение конкуренции между процессами

Что делать, если все лишние вызовы в диагностируемой пользователь­ской операции уже исключены, а время отклика по-прежнему непри­емлемо велико? Надо определить, насколько оправданны задержки в отдельных вызовах. Для того чтобы решить, допустима ли данная задержка, надо иметь представление о том, каких значений можно ожидать. Оказывается, эти значения состоят всего из нескольких со­ставляющих. Наиболее важные с нашей точки зрения перечислены в табл. 10.2. Эти значения будут меняться с увеличением скорости ра­боты оборудования, но на момент написания книги, в 2003 г., они представляют собой разумные ограничения для большинства сущест­вующих систем. В частности, значение LIO зависит от скорости рабо­ты процессора, все время стремительно увеличивающейся. Пояснения даны в сноске к табл. 10.2.

Событие	Максимально допусти­мая задержка на одно событие	Количество собы­тий в секунду при данной задержке
Logical read (LIO)a	20 мкс или 0,000 020 с	50000
Single-block disk read (PIO)	10 мс или 0,010 000 с	100
SQL*Net transmission via WAN	200 мс или 0,200 000 с	5
SQL*Net transmission via LAN	15 мс или 0,015 000 с	67
SQL*Net transmission via IPC	1 мс или 0,001 000 с	1000

a Джонатан Льюис (Jonathan Lewis) опубликовал результаты эксперимен­тов, согласно которым процессор, работающий на частоте 100 МГц, должен выполнять около 10 000 операций LIO в секунду [Lewis (2003)]. Следова­тельно, при частоте 1 ГГц ожидаемая производительность составит 100 000 LIO/сек, или 10 мкс на операцию. Указанное в таблице значение соответст­вуем частоте процессора 500 МГц.

Задержки, превышающие ожидаемые значения из табл. 10.2, могут свидетельствовать о сбоях в оборудовании, но чаще они вызваны за­держками в очередях к ресурсам. Чем вызваны длительные задержки в очереди? Наиболее вероятная причина (вы уже догадались?) - чрез­мерный спрос на ресурс. А чем вызван этот чрезмерный спрос? Оче­видно, одной или несколькими программами, конкурирующими за те же ресурсы, что и диагностируемая пользовательская операция.