DeepEdit!

Пользователи, работающие в оперативном режиме, выполняющие одну и ту же задачу вновь и вновь, чрезвычайно чувствительны к колебани­ям времени отклика. Если бы у них был выбор, то большинство, вероят­но, предпочло бы иметь постоянное двухсекундное время отклика онлайновой формы, чем такое же, в среднем двухсекундное, время откли­ка при 75% исполнений в течение одной секунды и 25% исполнений в течение семи секунд. Возможно, вы обратили внимание на то, что в системах с низкой загрузкой время отклика более или менее стабиль­но, но в сильно загруженных системах может очень сильно изменяться. Модель массового обслуживания объясняет, почему это происходит.

На рис. 9.19 изображено очень небольшое ухудшение времени откли­ка (от R1 к R2) многоканальной системы (т. е. m > 1) при увеличении коэффициента использования от значения р1 до р2. Обратите внима­ние, что значения R1 и R2 настолько близки друг к другу, что перекрываются соответствующие им метки на вертикальной оси. Однако спра­ва от излома даже очень небольшое изменение коэффициента исполь­зования от р3 к р4 приводит к серьезному ухудшению времени отклика (от R3 к R4).

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

А вот производительность одноканальных систем уменьшается более равномерно, как показано на рис. 9.20. На рисунке видно, что время отклика быстрее ухудшается справа от точки излома. Однако в систе­мах с небольшим количеством параллельных каналов (т. е. с неболь­шим значением m), такое ухудшение более равномерно распределено по всему диапазону значений коэффициента использования, чем в сис­темах с большим количеством параллельных каналов обслуживания (большими значениями m).

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

мах при переходе нагрузки за точку излома пользователи системы на­чинают ощущать значительные колебания времени отклика.

Чувствительность к параметрам

Электронные таблицы (Microsoft Excel и подобные) позволяют прове­рить различные ситуации типа «что, если» с такой быстротой, о кото­рой Агнер Эрланг мог только мечтать. Такие проверки могут избавить от бесконечных нервотрепок при общении с реальными конечными пользователями. Меня много раз просили определить, почему потер­пел неудачу проект повышения производительности. В ряде случаев модель массового обслуживания M/M/m позволила быстро и точно объ­яснить, почему усовершенствование оборудования не привело к ожида­емому положительному воздействию на общую производительность. Модель массового обслуживания часто позволяла привести аргументы такого вида:

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

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

Использование модели массового обслуживания M/M/m в электрон­ных таблицах учит нас тому, что каждый входной и каждый выходной параметр модели может служить предметом переговоров. Для того чтобы оптимизировать производительность системы, необходимо по­нимать, как параметры связаны друг с другом и какое экономическое воздействие оказывает выбор значения каждого из параметров. Рас­смотрим перечень таких параметров и возможные варианты выбора: X

Интенсивность поступления запросов X - это параметр, который может стать мощным рычагом в руках аналитика по производи­тельности. Многие аналитики вообще не рассматривают возможность обсуждения рабочей нагрузки с конечными пользователями, считая, что объем работы, который требуется от системы, жестко фиксирован. Но во многих случаях основной причиной ухудшения производительности системы является именно бесполезная нагруз­ка, например:

Приложение по расписанию отправляет уведомления по элек­тронной почте всем пользователям каждые две минуты, при этом каждый из них читает уведомления лишь дважды в день. То есть интенсивность поступления уведомлений можно было бы снизить в 120 раз, с 30 в час до 0,25 в час.

Система с восемью процессорами чрезвычайно замедляет работу с пользователями в период с 14:00 до 15:00. Основным элементом нагрузки для этого промежутка времени является набор из 16 от­четов (пакетных заданий), каждый из которых требует около 30 минут процессорного времени. Эти отчеты никто не будет чи­тать до 8:00 следующего дня. Таким образом, если запланировать запуск 16 пакетных заданий в полночь (вместо пиковых рабочих часов), то интенсивность поступления запросов на обслуживание процессором уменьшится настолько, что будет сэкономлено око­ло восьми часов процессорного времени в период с 14:00 до 15:00.

Для того чтобы определить, сходится ли дебет с кредитом в раз­личных бухгалтерских книгах, бухгалтеры каждый день фор­мируют 14 отчетов о предварительном балансе. Каждый 200-страничный отчет требует выполнения 72 000 000 вызовов логи­ческого чтения Oracle (LIO), что занимает около 30 минут про­цессорного времени. К сожалению, пользователи не знают, что приложение поддерживает веб-страницу, на которой можно по­лучить всю необходимую информацию о расхождениях в счетах, выполнив менее 100 операций LIO. То есть интенсивность посту­пления LIO для этих бизнес-операций можно снизить с миллиар­да в день до приблизительно 1400.

Как быстрее всего сделать что-то? Надо найти способ не делать это­го вообще. Часто оказывается, что этой цели вполне можно дос­тичь, не потеряв никакой функциональности для бизнеса.

r max

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

Как и в случае с rmax, пользователи, скорее всего, не захотят обсуж­дать p (долю времен отклика, которые не должны превышать rmax).