Соображения по использованию WorkManager'ов на сервере приложений Oracle WebLogic

В статье Потоки в управляемой среде. WorkManager мы рассмотрели как управлять многопоточностью в среде сервера приложений, но ничего не сказали о том, когда следует вмешиваться в работу самонастраиваемого пула потоков. В данной заметке мы постараемся исправить данный пробел.

Показания для вмешательства в работу пула потоков

Прежде всего следует помнить, что использование стандартного WorkManager'а (default) как правило является вполне допустимым решением: на каждое развернутое на сервере приложение будет создан свой WorkManager, имеющий настройки по-умолчанию. Дополнительные менеджеры потоков нужно определять лишь в следующих случаях:

• Приоритеты потоков по-умолчанию - все потоки имеют равный приоритет - нас не устраивают (Fair Share).
  
  
• Необходимо задать время ответа, к которому сервер приложений должен стремиться (Response Time).
  
  
• Возможны взаимоблокировки при взаимодействии сервер-сервер, в данном случае необходимо настроить WorkManager с явно заданным ограничением числа потоков снизу (Minimum Threads Constraint).
  
  
• При работе приложения используется общий для нескольких потоков пул соединений JDBC, тогда необходимо ограничить число этих потоков сверху (Maximum Threads Constraint).
  

Отдельно стоит заметить, что если на сервере приложений Oracle WebLogic развернута Oracle Service Bus, то для избежания взаимоблокировок при использовании Service Callout'ов необходимо, чтобы вызываемые таким образом сервисы имели отдельные WorkManager'ы. Подробнее про модель потоков OSB можно прочитать в одноименной статье.

О производительности: RouterRuntimeCache в Oracle Service Bus

В настройках Oracle Service Bus присутствует интересный параметр: com.bea.wli.sb.pipeline.RouterRuntimeCache.size. Данный параметр отвечает за то, сколько скомпилированных прокси-сервисов будет храниться в кэше. По-умолчанию его значение равно 100.

OSB реализует следующую логику - прокси-сервис компилируется при первом использовании и помещается в кэш. Если кэш переполнен (т.е. прокси-сервисов более 100), то сервисы удаляются из кэша, а затем, при последующих обращениях, повторно компилируются. Соответственно, если на шине развернуто много прокси-сервисов, что характерно для больших SOA-окружений, развернутых в крупных предприятиях со множеством филиалов, то ее производительность падает. Нужно увеличивать значение данного параметра.

Сделать это можно с помощью аргумента командной строки:

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000

Данный параметр можно добавить в определение переменной окружения EXTRA_JAVA_PROPERTIES в файле setDomainEnv.sh/cmd.

Понравилось сообщение - подпишитесь на блог и Twitter

Локальная оптимизация вызовов сервисов в Oracle SOA Suite

В Oracle SOA Suite реализован механизм локальной оптимизации вызовов сервисов, реализованных так же на Oracle SOA Suite. Т.е. если мы из одного композита вызываем с помощью Web Service Adapter сервис, реализованный в другом композите, то в реальности Oracle SOA Suite не будет формировать SOAP-сообщение и делать вызов по протоколу HTTP. Вместо этого он просто выполнит соответствующий код на JVM, на которой запущен Oracle SOA Suite, а значит и клиент сервиса, и его реализация.

Соответствующая оптимизация обладает как преимуществами, так и недостатками.

Преимущества:

• Повышение быстродействия: не тратится время на сериализацию параметров вызова в SOAP-сообщение, передачу данных по сети, а так же обратную десериализацию SOAP-сообщения с ответом.
  
  
• Распространение контекста транзакции: т.к. в реальности вместо сетевого взаимодействия вызывается код, работающий на той же JVM, то и инициатор вызова, и вызываемый сервис работают в рамках одной транзакции - если после изменения данных сервисом на клиенте произошел сбой, то транзакция откатывается и изменения не будут сохранены.
  

Недостатки:

• Отсутствие возможности балансировки нагрузки: при локальной оптимизации всегда будет вызван экземпляр сервиса, расположенный на том же узле кластера, на котором расположен клиент сервиса.
  
  
• Проблемы при работе механизма политик OWSM, в частности, связанных с безопасностью. Не все политики OWSM работают в режиме локальной оптимизации вызовов, соответственно, разработчик может ожидать, что для вызова из композита сервиса, реализованного в другом композите, будет требоваться авторизация, а в реальности, т.к. политика не сработала, то никакой авторизации не потребуется, сервис будет доступен любому пользователю.
  

Локальная оптимизация вызовов включена по-умолчанию, но ее можно отключить. Делается это путем выставления значения свойства oracle.webservices.local.optimization в false. Выставить данное свойство в false можно как в композите-провайдере сервиса, тогда локальная оптимизация будет отключена для всех вызовов сервиса, так и в композите-клиенте, тогда локальная оптимизация будет отключена только для этого клиента.

<binding.ws
    port="http://xmlns.oracle.com/CalledBPELProcessApp_
    jws/CalledBPELProcess/CalledBPELProcess#wsdl.endpoint(calledbpelprocess_client_
    ep/CalledBPELProcess_pt)"
    location="http://localhost:8001/soa-infra/services/default/CalledBPEL
    Process!1.0/calledbpelprocess_client_ep?WSDL">
      <wsp:PolicyReference URI="oracle/wss_username_token_client_policy"
                           orawsp:category="security"
                           orawsp:status="enabled"/>
      <wsp:PolicyReference URI="oracle/log_policy"
                           orawsp:category="management"
                           orawsp:status="enabled"/>
      <property name="oracle.webservices.local.optimization">false</property>
</binding.ws>

Понравилось сообщение - подпишитесь на блог и Twitter