Real User Experience Insight
На семинаре RAC DD4D после моего рассказа о Response Time Formula и ее измерении внутри БД, возникло несколько вопросов, а как померять время отклика в целом для приложения. В частности для случая сервера приложений. Поскольку сервер приложений использует пул соединений и со стороны БД при плохом проектировании может быть сложно отличить один бизнес-процесс от другого.
Так вот, у Oracle есть специальный продукт для этого случая - Oracle Enterprise Manager Real User Experience Insight.
Продукт достаточно уникальный тем, что измеряет время отлика не инструментируя приложение (как Veritas I3, например), а анализируя сетевой траффик. Таким образом, может быть измерено время отклика для пользователей любого сервера приложений, не обязательно написанного на java.
Отсылаю вас за подробностями к white paper. В Oracle этой темой владеет Сергей Иванович Томин.
Сообщения
Насколько я понял, этот продукт только для Application Server.
ОтветитьУдалитьC базой он не работает?
С i3 его не стоит сравнивать, не тот уровень.
Как вытащить запросы который используют процессор (и другие метрики, не только сеть) только по анализу сетевого траффика?
RUEI интересный и красивый продукт.
ОтветитьУдалитьСнифферит сетевой трассив и анализирует пакеты на ходу, выводя подробные отчёты о нагрузке сети, времени отклика отдельных страниц, может строить KPI (Key Performance Indicator) и многое другое...
Мы (Форс) сейчас собрали тестовый стенд для RUEI.
Из найденных минусов то, что RUEI начисто не понимает русский. Это создаёт большие проблемы для продажи его на территории СНГ.
Про цену промолчу уж :)
Копаем дальше пока...
>Насколько я понял, этот продукт только для Application Server.
ОтветитьУдалитьНет, просто он сам по себе работает в виде веб-приложения на выделенном апп. сервере.
>С i3 его не стоит сравнивать, не тот уровень.
i3 и ему подобные тулзы делают очень серьезное внедрение в код java приложения. А именно используют JVMPI/JVMTI для модификации байт-кода на лету и внедрения туда своих callback'ов. Это, во-первых, серьезно влияет на производительность, а во-вторых, может ограничивать возможности JVM, т.к. по сути используются debug-интерфейсы которые вносят доп. ограничения. Например, могут быть отключены/некорректно работать некоторые опции GC.
>Как вытащить запросы который используют процессор (и другие метрики, не только сеть) только по анализу сетевого траффика?
Очевидно что в общем случае никак, т.к. выполнение запроса это не один DB-call а минимум 2 (exec+fetch). Теоретически можно парсить T4C траффик (если используется jdbc thin driver), но это будет жесть. Нормальный способ - это инструментирование кода приложения (простановка MODULE/ACTION/CLIENT_IDENTIFIER/CLIENT_INFO) либо c помощью явных вызовов dbms_application_info/dbms_session, либо с помощью дополнительных интерфейсов (end-to-end metrics - в этом случае не будет roundtrip'ов до сервера, информация будет передаваться в последующих DB-calls). После этого приложение становится DB-friendly, и можно использовать стандартный инструментарий Оракла для анализа активности определенных end-user sessions с помощью dbms_monitor & trcsess & tkprof.
Hanatsu,
ОтветитьУдалитьПо поводу русского языка (да и любых других вопросов по RUEI) напишите по адресу (jeroen.van.driel гав-гав oracle.ком). Надо написать по-английски, сказав откуда Вы и что у Вас уже есть стенд. Надо также написать с какими именно русскими кодировками есть проблемы. Jeroen van Driel является product manager по RUEI. Он все подробно расскажет и соединит с правильными техническими людьми. Кроме этого, на днях выходит новая версия RUEI. Я ему сейчас ему звонил и предупредил, что Вы напишите. Не копайте в одиночку. Копайте в контакте с RUEI product managеment!
Спасибо, Сергей!
ОтветитьУдалитьМы уже общаемся с Михаилом Энци из Oracle по данному вопросу.
Но контакт сохраню на всякий случай.
Сейчас как раз ждём новой версии. с текущей, в общем-то, разобрались.
А как насчет штатных средств, входящих в Oracle iAS EE, скрипты для загрузки в базу логов iAS? Ну, того, что лежит в $OH/portal/admin/perf ? Базу они, разумеется, не мониторят, но сетевую производительность и application.log получить в базу можно, а там уж и анализировать.
ОтветитьУдалитьСетевые latency можно получить через спецформат лога webcache (Doc id 278805.1).
Oracle более-менее поддерживает в актуальном состоянии первое из вышеупомянутого. Правда, это не real-time monitoring, надо признать... Скорее off-line analysis. Но тем не менее, Oracle планирует отказываться от этих средств в пользу Insight?
Разумеется, никто не имеет понятия, в каком направлении пойдёт Oracle. Их настроение меняется год от года :)
ОтветитьУдалитьЧто касается RUEI в частности, то это скорее грамотное средство для потроения для KPI (Key Performance Indicator). Это полезно для очень жирных заказчиков, которые, к примеру, хотят отдать свой веб-сайт на аутсорсинг, но хотят прописать различные параметры в SLA (Service Level Agreement).
Базовыми средствами выстраивать подобные индикаторы довольно затруднительно. А с помощью RUEI очень легко.
Вторым полезным свойством я считаю возможность построения т.н. транзакционной воронки. Причём подразумевается именно бизнес-транзакция. Путь следования пользователя от открытия страницы до оформления заказа. Можно посмотреть, на каком этапе пользователи останавливаются, и понять, что скорректировать для оптимизации бизнеса.
Но всё-таки инструмент предназначен для произвольных сайтов. Нет необходимости копать логи iAS, и изобретать велосипед, писать свои средства анализа, вычисления KPI, когда есть стандартный механизм.
Единственный минус - цена. Так что, предназначен он именно для жирных заказчиков.
Hanatsu: Понятно. В любом случае, софт заслуживает внимания, особенно если можно скачать-посмотреть.
ОтветитьУдалить