DeepEdit!

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

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

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

Сопутствующая выгода от уменьшения нагрузки может быть ошелом­ляющей. Математически это обосновано в главе 9.

Запросы и услуги в технологическом стеке

Как же исключить бесполезную нагрузку? Ответ зависит от уровня технологического стека. Понятие технологического стека системы было введено в главе 1, когда рассматривалось представление времени отклика пользовательской операции при помощи диаграммы последовательности. Технологический стек состоит из взаимодействующих друг с другом уровней, выступающих в роли поставщиков и потреби­телей, как показано на рис. 10.1. Отношения между ними просты.

Такое представление технологического стека помогает понять фунда­ментальную аксиому повышения производительности:

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

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

Действительно ли оправдан столь высокий спрос на данный ресурс?

Рассмотрим профиль ресурсов, приведенный в примере 10.3. Без ма­лого 97% времени отклика исследуемой пользовательской операции, составляющего 1,3 часа, расходуется на ожидание дискового ввода/ вывода. Согласно профилю ресурсов, возможны два решения:

Уменьшить количество вызовов, сделав так, чтобы оно не превыша­ло 12165.

Уменьшить среднюю длительность вызова, сделав так, чтобы она не превышала 0,374109 секунды.

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

Response Time Component	Duration		# Calls	Dur/Call
db file scattered read	4,551.0s	96.9%	12,165	0.374109s
CPU service	78.5s	1.7%	215	0.365023s
db file sequential read	64.9s	1.4%	684	0.094883s
SQL*Net message from client	0.1s	0.0%	68	0.001324s
log file sync	0.0s	0.0%	4	0.010000s
SQL*Net message to client	0.0s	0.0%	68	0.000000s
latch free	0.0s	0.0%	1	0.000000s
Total	4,694.5s	100.0%

Как уменьшить количество событий, выполняемых пользовательской операцией? Во-первых, выясните, что именно делает потребляемый ре­сурс. Что заставляет процесс Oracle, профиль которого приведен в при­мере 10.3, выполнять 12 165 вызовов многоблочного чтения? Затем выясните, можно ли обеспечить требуемую функциональность мень­шим числом обращений к ресурсу. В главе 11 объясняется, как это сделать для нескольких часто встречающихся событий Oracle. Опреде­лите, можно ли ограничить потребность в перегруженном ресурсе, пройдя по всем уровням технологического стека. Например:

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

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

Поднявшись по стеку еще выше, можно обнаружить еще более про­стые пути достижения результата. Например, может выясниться, что данная пользовательская операция может выполняться реже или не выполняться вообще (возможно, ее удастся чем-нибудь заме­нить), и это никак не скажется на ценности системы для бизнеса.