Short intro: here you can find a small article regarding performance tuning of UI app OIM 11gR2PS1...
В связи с проходящими внедрениями последней на данный момент версии Oracle Identity Manager 11gR2PS1 (11.1.2.1) и поступающими вопросами от интеграторов и заказчиков имеет смысл поговорить о настройке скорости работы пользовательского интерфейса приложения самообслуживания (приложение Identity) OIM.
Начну с того, что по словам Product Management данная версия OIM работает в продуктивных средах сразу у нескольких заказчиков по миру и нареканий со стороны производительности не вызывает. Значит, интеграторы в российских внедрениях "просто его не умеют готовить"? Давайте попробуем разобраться.
UI приложения Identity написан на ADF2.0, который неизбежно тянет на сторону клиента большое количество javascript'а и картинок. Поэтому важно уметь настроить кэш на стороне сервера, конфигурировать компрессию на стороне сервера, чтобы свести к минимуму сетевые задержки и настраивать соответствующие заголовки.
Общий подход к настройке производительности UI Oracle Identity Manager 11gR2PS1 приведен в статье на MOS под номером 1557879.1 (OIM 11gR2: Patches for Performance Issues Related to Self-service UI). Таким образом, начать необходимо с применения последнего Bundle patch'а (на текущий момент это BP03 к OIM 11.1.2.1 под номером 17532765, т.е. получится версия 11.1.2.1.3). Далее рекомендуется поставить патч к ADF 16911113 (часть, относящуюся к JDeveloper теоретически можно проигнорировать).
В инструкции патча BP03 есть раздел, посвященный оптимизации производительности, который вводит новую категорию кэш-объектов и т.д. Этот раздел, как и настройку КЭШа, необходимо выполнить. Также необходимо выполнить настройку JVM, поднять объем Java Heap, количество соединений в БД и выполнить настройку БД в соответствии с документом Oracle Fusion Middleware Performance & Tuning Guide 11g Release 2 (http://docs.oracle.com/cd/E37115_01/doc.1112/e28552/toc.htm).
Настроить ADF приложения Identity, с которым работают конечные пользователи, можно, вставив в строку запуска сервера приложений OIM (startManagedWeblogic.cmd) следующие свойства:
-Djbo.ampool.doampooling=true -Djbo.ampool.minavailablesize=1
-Djbo.ampool.maxavailablesize=120 -Djbo.recyclethreshold=60
-Djbo.ampool.timetolive=-1 -Djbo.load.components.lazily=true
-Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1
-Djbo.connectfailover=false -Djbo.max.cursors=5
-Doracle.jdbc.implicitStatementCacheSize=5
-Doracle.jdbc.maxCachedBufferSize=19
Настроить кэш для приложения Identity можно через Enterprise Manager: Identity and Access Management -> OIM -> oim 11.1.2 -> System MBean Browser -> oracle.iam -> XMLConfig -> Config -> XMLConfig.CacheConfig -> Cache -> XMLConfig.CacheConfig.CacheCategoryConfig –> Attributes. Для всех категорий кроме "StoredProcAPI" надо установить Enable=true. Проверить настройку кэша можно, выгрузив из MDS файл /db/oim-config.xml и убедиться, что необходимые категории кэша там присутствуют (включая созданные при установке патча BP03) и атрибут Enabled установлен в значение true.
Быстродействие системы определяется множеством факторов, совсем не всегда зависящих от вендора, и приведенные здесь рекомендации – лишь некоторое из того, что необходимо сделать. На моей тестовой конфигурации (VBox VM на ноутбуке, Windows Server 2008R2, JDK1.6.0_45, VMRAM 12Гб) производительность системы нормальная. Впрочем, практика показывает, что реальное внедрение всегда отличается от модели на тестовом стенде, и если вы столкнулись с проблемами производительности, связанными с ПО OIM, немедленно создавайте Service Request на My Oracle Support. При необходимости его можно эскалировать и обратиться за помощью PM, написав мне.
Ниже можно найти документ, примерно описывающий другие шаги по настройке производительности OIM…
OIM11gR2 Performance Tuning Guide.
В связи с проходящими внедрениями последней на данный момент версии Oracle Identity Manager 11gR2PS1 (11.1.2.1) и поступающими вопросами от интеграторов и заказчиков имеет смысл поговорить о настройке скорости работы пользовательского интерфейса приложения самообслуживания (приложение Identity) OIM.
Начну с того, что по словам Product Management данная версия OIM работает в продуктивных средах сразу у нескольких заказчиков по миру и нареканий со стороны производительности не вызывает. Значит, интеграторы в российских внедрениях "просто его не умеют готовить"? Давайте попробуем разобраться.
UI приложения Identity написан на ADF2.0, который неизбежно тянет на сторону клиента большое количество javascript'а и картинок. Поэтому важно уметь настроить кэш на стороне сервера, конфигурировать компрессию на стороне сервера, чтобы свести к минимуму сетевые задержки и настраивать соответствующие заголовки.
Общий подход к настройке производительности UI Oracle Identity Manager 11gR2PS1 приведен в статье на MOS под номером 1557879.1 (OIM 11gR2: Patches for Performance Issues Related to Self-service UI). Таким образом, начать необходимо с применения последнего Bundle patch'а (на текущий момент это BP03 к OIM 11.1.2.1 под номером 17532765, т.е. получится версия 11.1.2.1.3). Далее рекомендуется поставить патч к ADF 16911113 (часть, относящуюся к JDeveloper теоретически можно проигнорировать).
В инструкции патча BP03 есть раздел, посвященный оптимизации производительности, который вводит новую категорию кэш-объектов и т.д. Этот раздел, как и настройку КЭШа, необходимо выполнить. Также необходимо выполнить настройку JVM, поднять объем Java Heap, количество соединений в БД и выполнить настройку БД в соответствии с документом Oracle Fusion Middleware Performance & Tuning Guide 11g Release 2 (http://docs.oracle.com/cd/E37115_01/doc.1112/e28552/toc.htm).
Настроить ADF приложения Identity, с которым работают конечные пользователи, можно, вставив в строку запуска сервера приложений OIM (startManagedWeblogic.cmd) следующие свойства:
-Djbo.ampool.doampooling=true -Djbo.ampool.minavailablesize=1
-Djbo.ampool.maxavailablesize=120 -Djbo.recyclethreshold=60
-Djbo.ampool.timetolive=-1 -Djbo.load.components.lazily=true
-Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1
-Djbo.connectfailover=false -Djbo.max.cursors=5
-Doracle.jdbc.implicitStatementCacheSize=5
-Doracle.jdbc.maxCachedBufferSize=19
Настроить кэш для приложения Identity можно через Enterprise Manager: Identity and Access Management -> OIM -> oim 11.1.2 -> System MBean Browser -> oracle.iam -> XMLConfig -> Config -> XMLConfig.CacheConfig -> Cache -> XMLConfig.CacheConfig.CacheCategoryConfig –> Attributes. Для всех категорий кроме "StoredProcAPI" надо установить Enable=true. Проверить настройку кэша можно, выгрузив из MDS файл /db/oim-config.xml и убедиться, что необходимые категории кэша там присутствуют (включая созданные при установке патча BP03) и атрибут Enabled установлен в значение true.
Быстродействие системы определяется множеством факторов, совсем не всегда зависящих от вендора, и приведенные здесь рекомендации – лишь некоторое из того, что необходимо сделать. На моей тестовой конфигурации (VBox VM на ноутбуке, Windows Server 2008R2, JDK1.6.0_45, VMRAM 12Гб) производительность системы нормальная. Впрочем, практика показывает, что реальное внедрение всегда отличается от модели на тестовом стенде, и если вы столкнулись с проблемами производительности, связанными с ПО OIM, немедленно создавайте Service Request на My Oracle Support. При необходимости его можно эскалировать и обратиться за помощью PM, написав мне.
Ниже можно найти документ, примерно описывающий другие шаги по настройке производительности OIM…
OIM11gR2 Performance Tuning Guide.
Олег, привет
ReplyDeleteа на каком количестве УЗ записей выполнялась проверка?
Ведь, если я не ошибаюсь, снижение производительности наблюдается именно с увеличением количества пользователей.
порядка сотни...
Deleteя полагаю, что на большом количестве пользователей, конечно, будут свои проблемы, но тут разговор о том, что без вышеописанных действий и на 200 пользователях есть проблемы с производительностью
помимо количества пользователей важно, что им назначено и т.д., в-общем, там масса факторов, постепенно стенд будем усложнять, чтобы выявить проблемы и добиваться их решения через саппорт
сильно облегчило бы задачу наличие "устойчиво медленно работающего" use case'а