DeepEdit!

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

Для начала исследуем интересный результат моделирования, что­бы понять, почему добавление процессоров не приводит к возраста­нию интегральной функции распределения времени отклика более, чем до 87%. Модель показывает, что даже сто систем по сто процес­соров в каждой не могут предложить удовлетворяющего пользова­телей времени отклика в более, чем 87% случаев.

Причина в том, что время обслуживания в модели M/M/m - это случайная величина. Несмотря на то, что среднее время обслужива­ния постоянно, реальное время обслуживания для определенного типа функций меняется от одной функции к другой. Например, двум идентичным SQL-запросам с разными значениями перемен­ных связывания в предикате инструкции where могут соответство­вать несколько отличающиеся количества операций LIO, из-за чего отличается и время обслуживания процессором. Увеличивая коли­чество процессоров в системе, мы уменьшаем лишь составляющую средней задержки в очереди (W) для времени отклика (R = S + W). Если среднее время обслуживания само по себе достаточно близко к допустимому пределу, то случайных колебаний времени обслу­живания будет достаточно для того, чтобы время отклика превыси­ло указанный предел для значительного (в процентном отношении) количества выполнений.

На самом деле для нашей важной команды SQL не будет пользы от увеличения количества процессоров сверх шести.

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

Если бы удалось соответственно снизить интенсивность поступле­ния запросов в пиковое время для нашей задачи с

команд в секунду до

команд в секунду, то нагрузка, порождаемая данной командой, уменьшилась бы в 240 раз. Результатом будет значительный выиг­рыш в масштабируемости. Системе потребуется всего один процес­сор для обеспечения удовлетворяющего пользователей времени от­клика в 87% исполнений команд.

Интенсивность запросов X представляет собой отношение величин A/T, поэтому существуют два способа ее уменьшения. Во-первых, можно уменьшить числитель A, т. е. количество поступлений за­просов в систему (это я уже предлагал). Во-вторых, можно увели­чить знаменатель T, период времени, в течение которого система должна принять указанное количество запросов.

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

Допустимый предел времени отклика rmax и процентиль успеха p

Действительно ли для бизнеса необходимо, чтобы время отклика для той самой важной команды составляло менее одной секунды? Действительно ли это требуется в 95% случаев? Такие вопросы сле­дует задавать шепотом, т. к. они относятся к самому сокровенному. Пользователи часто считают, что эти условия не подлежат обсужде­нию, но важно, чтобы они понимали, что жесткая позиция по дан­ному вопросу повышает требования к стоимости системы, что мо­жет оказаться неприемлемым для бизнеса. Например, если согла­сие на 100 дополнительных секунд времени отклика в день будет означать экономию 100 000 долларов в год, то, вероятно, на такое предложение стоит откликнуться. Если компания готова пойти на снижение планки до обеспечения 95% успеха для rmax = 1,5 секун­ды, то вам удастся обеспечить необходимую производительность для изначально запрошенной интенсивности поступлений (X» 6,666667 команд в секунду) с помощью шести процессоров. Если же компания готова обсуждать и снижение интенсивности поступ­ления запросов, то при значении X » 0,027778 команд в секунду на­шу задачу можно решить при помощи всего одного процессора.

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

Так, если удастся уменьшить время обслуживания важной коман­ды с 0,49 секунды до 0,3125 секунды, то скорость обслуживания для команды возрастет с л = 2,04 команд в секунду до л = 3,2 ко­манд в секунду. Если удастся увеличить скорость обслуживания именно настолько, то исходное требование rmax = 1,0 будет удовле­творено в 95% выполнений команды при условии использования четырех процессоров. Если же можно повысить скорость обслужи­вания до /=10 команд в секунду (например, оптимизировав SQL так, что среднее время обслуживания достигнет 0,1 секунды), то требования к производительности можно удовлетворить даже по­средством одного процессора.

Я считаю, что главная ценность модели массового обслуживания M/M/m в том, что она показывает, в каком направлении следует действовать. В только что рассмотренном примере вы узнали, что не стоит даже по­мышлять об установке более чем шести процессоров для обслуживания важной команды. Узнали о том, что договоренность с пользовате­лями о некотором увеличении значения rmax позволит вам вздохнуть чуть свободнее. Но только снизив частоту выполнения пользователя­ми важной команды (X) или же уменьшив время обслуживания ко­манд S = 1//), вы получите систему, которая наилучшим образом соот­ветствует требованиям к производительности.

Использование возможности подбора параметра в Microsoft Excel

Microsoft Excel предлагает средство под названием Goal Seek (Подбор параметра), позволяющее ответить на многие из поставленных вопро­сов. Оно предоставляет возможность рассматривать любые выходные значения модели в качестве своих входных параметров. Предполо­жим, что требуется определить, какая средняя скорость обслужива­ния понадобится для того, чтобы довести удовлетворенность пользова­телей временем отклика до 95% при фиксированном значении m.

Решить задачу можно следующим образом. Сначала вводим для / про­извольное постоянное значение (на рис. 9.24 /=1). Затем выбираем пункт меню Сервис Подбор параметра (Tools Goal Seek) для вызо­ва диалогового окна выбора параметра (рис. 9.25). Наша задача состо­ит в том, чтобы довести значение CDF(rmax) до 95%, изменяя /. На рис. 9.26 в ячейке для и показано значение, полученное в результате выполнения операции подбора параметра. Оказывается, что желаемо­го результата можно достигнуть при / « 10.

Анализ чувствительности

Качество прогнозирования времени отклика прямо зависит от качества «контура обратной связи», применяемого для уточнения прогноза. По­лучив старательно подготовленную формулировку задачи и модель массового обслуживания, практически каждый сможет получить пра­вильные количественные показатели. Но при этом важно устоять перед искушением прекратить мыслительную деятельность сразу же после того, как модель «дала ответ». Получив ответ, следует потратить еще некоторое количество времени на чрезвычайно важное занятие - ана­лиз чувствительности, которым пренебрегают 99% аналитиков, впер-

Рис. 9.25. Наша цель - довести значение CDF(rmax) до 95%, изменяя значение л

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

Наряду с выходными параметрами модели необходимо также учиты­вать следующие факторы:

Естественно, нельзя установить какую-то часть процессора. Коли­чество процессоров в системе должно быть целым числом. Некото­рые системы могут требовать установки процессоров парами. Разу­меется, максимальное число процессоров, которые могут быть уста­новлены в системе, тоже ограничено.

Модель массового обслуживания ничего не знает о тех недостатках, которые не позволяют системе с m процессорами обеспечить увели­чение производительности в m раз. Например, для получения шес­тикратной производительности сервера Linux, потребуется уста­новка восьми или более процессоров. А в ОС Windows NT может оказаться, что независимо от того, сколько процессоров может фи­зически вместить сервер, никакая конфигурация системы не позво­лит увеличить производительность более чем в два раза. Аналитик по производительности должен в своей работе учитывать несовер­шенство масштабируемости, препятствующее m-кратному прирос­ту производительности реальной системы с m процессорами.

Формулировка задачи упоминает лишь об одной команде SQL, но на самом деле система почти наверняка будет выполнять и какие-то другие полезные действия. Поэтому результат моделирования для данного конкретного случая следует интерпретировать так: «Количе­ство процессоров, необходимых для обеспечения требуемого времени отклика команды SQL примерно на 5 больше того количества, кото­рое требуется для поддержки всей остальной нагрузки системы».

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

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

Общая производительность системы чрезвычайно чувствительна даже к небольшим изменениям средней скорости обслуживания (л) и средней интенсивности поступлений запросов (X). Это отражается в модели. По своей природе данные параметры исключительно сильно влияют на общую производительность, из-за чего погреш­ность в их оценке ставит под сомнение результат моделирования.

Например, завышение средней скорости обслуживания всего на 1% может привести к занижению среднего времени отклика в загру­женной системе на 10% или даже более. Изменение величин / и X может быть вызвано следующими обстоятельствами:

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

Изменения объема данных, особенно для SQL-запросов, произ­водительность которых линейно (или в большей степени) зави­сит от объема обрабатываемых данных [Millsap (2001a)].

Изменения физического распределения данных, которые могут со временем повысить или понизить эффективность индекса (или его полезность для оптимизатора запросов Oracle) [Millsap

(2002)].

Изменения кода функции, такие как изменения команд SQL или объектов схемы, вызванные модернизацией оборудования, рабо­тами по повышению производительности или чем-то еще.

Изменения объема бизнес-функции, вызванные приобретения­ми и поглощениями, неожиданными успехами или неудачами маркетинговых компаний и т. д.

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