Около полугода назад я делал перевод статьи по оптимизации производительность Apex приложений - "Sizing Up Performance":
Заканчиваем перевод статьи Sizing Up Performance, начатый в постах "Повышаем производительность (часть 1)" и "Повышаем производительность (часть 2)".
Оптимизация элементов страниц
Другими общедоступными возможностями настройки производительности приложений Oracle Appliccation Express являются такие элементы, как процессы(Page processes), вычисления(computations),авторизация(authorizations), валидация(validations) и условия (conditions). Производительность этих элементов на странице должна быть очевидной при работе приложения в режиме отладки (debug mode). Ниже приведены рекомендации для этих элементов страницы:
Устанавливайте момент запуска процесса на уровне страницы (page processes) - один на страницу (per-page), а не на сессию. Если же используется процесс на уровне приложения (application-level processes) , то можно установить момент запуска - один на сессию (per session) или на показ страницы (page view). Имейте в виду, что использование опции по сессионного старта процесса уровня приложения, может повлиять на отображение всех страниц приложения.
Оптимизируйте составляющие нулевой страницы (особенности этой страницы описаны здесь). Компоненты этой страницы отображаются на каждой странице приложения, поэтому стоит уделить особое внимание оптимизации логики именно этой страницы. Объединяйте различные PL/SQL блоки в пакеты, то есть, если на странице есть большие PL/SQL блоки, то лучше перенести эти блоки в PL/SQL пакет и вызывать его из приложения.
Используйте декларативные условия. Такия условия быстрее, чем динамический SQL или PL/SQL-условия. Например, использование условие типа "Item=Value" будет быстрее, чем использование PL/SQL-выражения ":ITEM=value."
Для отчетов, содержащих большое количество строк, лучше использовать нумерацию страниц типа "Rows X to Y". Нумерация типа "Rows X to Y of Z" занимает больше времени на выполнение, чем простая нумерация типа "Rows X to Y". Например, если в отчете, содержащем 900 строк, используется нумерация типа "Rows X to Y of Z", Oracle Application Express будет должен выполнить полную выборку данных, чтобы установить количество строк. А при использовании нумерации типа "Rows X to Y", будет необходимо выбрать только Y + 1 строку.
Выводы
Использование представленного материала, поможет оценить производительность и масштабируемость приложений Oracle Application Express. Если производительность приложения оставляет желать лучшего, то использование выше представленных подсказок поможет установить самые медленные страницы и определить на них плохо реализованные компоненты. Используя данную информацию, можно будет гарантировать, что ваши приложения Oracle Application Express будут соответствовать заявленным требованиям по производительности.
Продолжаем перевод статьи Sizing Up Performance о проблемах производительности в приложениях Oracle Application Express, начатый в предыдущем посте.
Поиск и устранение узких мест
Накладные расходы, связанные с созданием страницы в Apex, довольно статичны. Время потраченное на обработку SQL или PL/SQL кода, созданного разработчком, добавляется к тому, которое было использовано для генерации страницы. Используя "Monitor Activity", можно легко определить наихудшие по производительности страницы приложений:
После того, как определена самая медленная страница приложения, можно изучить ее в режиме отладки, нажав ссылку "Debug" в панели инструментов разработчика.
В режиме отладки, отдновременно с выводом самой страницы, выводится и информация о затраченном на вывод времени: отражаются временные интервалы, соответствующие конкретным действиям Oracle Application Express, а так же такая дополнительная информация, как названия элементов страницы, вычисления, точки обработки.
Найти узкое место по производительности на странице довольно просто, для этого достаточно лишь опредедлить скачек потраченного времени в отладочных сообщениях. Например, ниже следует кусок отладочных сообщений:.
.
.
0.05: Region: Projects
0.06: Show report
0.06: Determine column headings
0.06: Activate sort
0.07: Parse query as: MIKE1
0.07: Binding: ":P24_SEARCH"="P24_SEARCH" value=""
0.07: Print column headings
0.07: Rows loop: 15 row(s)
0.18: Region: Icon View
.
.
.
Очевиден скачек потраченного времени с 0.07 секунд до 0.18. Этот скачок свидетельствует о том, что запрос занимает 0.11 секунд на выполнение, которое в данном примере имеет значительную долю в общем времени вывода страницы и, таким образом, является отличной целью для оптимизации.
Настройка SQL
Наиболее распространенной областью настройки является SQL. Движок Oracle Application Express выполняет разбор, связывание, непосредственное выполнение и получение результирующих данных SQL-запросов отчетов. Использование связанных переменных (bind variables) везде, где это возможно, избавляет от ненужного разбора и способствует повторному использованию планов SQL-запросов.
Кроме того, необходимо убедиться, что для запроса используется оптимальный план. Для генерации плана запроса можно использовать "Explain Plan" в окне "SQL Commands".
Для более тщательного изучения каждого фрагмента SQL или PL/SQL кода на каждой странице, можно включить для нее SQL-трассировку. SQL-трассировка сгенерирует трейс файл на серевере, который можно будет проанализировать Oracle утилитой - TKPROF. (более подробную информацию об использовании TKPROF в Oracle Application Express можно найти в разделе Debugging an Application в "Oracle Application Express User's Guide")
(прим. автора - подробнее о связываемых переменных, планах выполнения, жестком/мягком разборе запросов и трассировке можно почитать в книге Т.Кайта "Oracle для проффесионалов").
... продолжение следует ...
Листал на днях Oracle Magazine, и наткнулся на давольно интересную статью про оценку прозводительности приложений Apex. После беглого просмотра обратился к русской редакции данного журнала и, к своему удивлению, обнаружил, что перевода ее нет :(. После недолгих раздумий решил исправить положение :)...
Советы и методы для оптимальной производительности Oracle Application Express
В силу того, что Oracle Application Express становится все более популярным, все больше пользователей ищут руководства по настройке производительности для Apex приложений. Ниже будет продемострирован быстрый и удобный способ для оценки и изменения производительности. Так же будет продемонстрировано, как идентифицировать и решать проблемы производительности. Ниже перечислены наиболее общие вопросы, которые будут освещены:
Понимание понятия "производительность" в приложениях Oracle Application Express
Ключ к оптимальной производительности для большинства приложений Oracle Application Express заключается в том, чтобы сохранять среднее время отображения страницы относительно небольшим. Масштабирование линейно: приложение со среднем временем вывода страницы в 10 милисекунд может быть вызвано в 10 раз больше конкурирующими пользователями, чем приложение со среднем временем вывода страницы в 100 милисекунд.
Для беглой оценки производительности приложений Apex, можно использовать статистику собранную Apex'ом, информация о которой доступна на странице "Monitor Activity". Если предположить, что приложение хорошо оптимизировано, включая эффективный SQL и PL/SQL, то самым важным изменяемым фактором является количество процессоров (CPU).
Например, предположим, что разрабатывается приложение, которое должно обеспечивать 1000 показов страниц в минуту. Для системы с двумя процессорами, приложение должно обеспечивать 500 показов страниц в минуту на один процессор или 8.33 показа в секунду/процессор. Для того, чтобы удовлетворить этим требованиям, необходимо, чтобы среднее время вывода страницы не превышало 120 милисекунд.
Отношение между доступным числом процессоров и требуемым числом показов страниц в минуту, выраженное в среднем времени отклика на страницу, может быть отражено с помощью следующей формулы:
(N*60)
------ = A
P
, где:
Используя это простое уравнение, можно выполнять оценку среднего времени отображения страницы для обеспечения заданного числа показов страниц в минуту. Изменяя число процессоров или количество показов страниц в минуту, можно установить четкие целевые показатели для приложения.
Кроме того, среднее время отображения страницы может помочь в предсказании влияния изменения размера пользователей, то есть, для того, чтобы определить количество пользователей, которое может обеспечивать приложение, начиная с первого определения количества запросов страниц в течение определенного периода времени.
Например, если средняя сессия, включающая 50 показов страниц, занимает 10 минут,а приложение поддерживает отображение пяти страниц в минуту для обычной сессии, то если приложение масштабируется для обеспечения 1000 показов страниц в минуту, то приложение будет поддерживать 200 одновременных пользователей на сессию.
Если экстраполировать эти данные для оценки количества ежедневных пользователей, то давайте так же считать, что все пользователи находятся в одном часовом поясе и, что в среднем каждый пользователь использует две сессии в один восьмичасовой рабочий день, в результате чего имеем 100 страниц (2 * 50 страниц в сессии). Поскольку приложение масштабируется на 1000 показов страниц в минуту,то умножим число минут в восьми часах (480) на страницы в минуту (1000), чтобы определить, что приложение может обеспечивать 480000 показов страниц на каждые восемь часов, или 4800 пользователей.
Как правило, приложение необходимо масштабировать для самого загруженного часа, так как нагрузка может быть 100 страниц в минуту в течение дня, а может быть и 1000 просмотров страниц в минуту в час пик.
Другое правило состоит в том, что необходимо обеспечивать среднее время показа страницы 300 милисекунд или менее. Для высоко производительных приложений, с многими сотнями или тысячи пользователей, необходимо стремиться к среднему времени показа страницы 150 милисекунд или менее.
... продолжение следует...
