Рекомендуемые параметры конфигурации HTTP plug-in

Эта статья – “best practices” по настройке параметров Plug-in.

LoadBalanceWeight

Начальный статический вес участников кластера для распределения нагрузки при использовании карусельного  метода (Round Robin). Рекомендуемые значения: все участники максимально возможный вес, т.е. 20, один из участников должен иметь максимальный вес-1. Например 3 участника: 20, 20, 19 Где производить настройки в админ. консоли: Серверы > Кластеры > Кластеры серверов приложений WebSphere > имя_кластера > Участники кластера. Свойство “Настроенный вес”.

MaxConnections

Максимально возможное число одновременных соединений, обрабатываемых сервером. Это относится только к новым запросам/соединениям, без учета сессионных запросов (affinity-requests), и не используется для того, что бы пометить сервер как «неработающий» (mark the server “down”).

По умолчанию значение (-1). Этого достаточно в идеальных условиях, если сервер, точнее приложение быстро обрабатывает запросы, тогда запрос будет на рассмотрении (pending, отложенный запрос) очень короткий промежуток времени. Но чаще всего, нагрузка на сервера приложений меняется со временем, и бывают пики нагрузки, когда сервера приложений (приложения на них) не могут быстро обрабатывать запросы, следовательно, количество отложенных запросов растет.

Свойство MaxConnections устанавливает ограничение на количество отложенных (pending) запросов. Когда MaxConnections достигнуто, сервер не помечается как “down”, он просто не принимает новых запросов.

Рекомендации:

  • Если обычно запросы обрабатываются менее 1 сек (время отклика), то MaxConnections=20 (или около того)
  • Если обычно запросы обрабатываются несколько секунд (время отклика), то MaxConnections=100 (или около того)
  • Рекомендуемый диапазон значений 20-100, в зависимости от времени отклика.

Этот атрибут игнорируется на платформе z/OS. Контрол регион (CR) z/OS, работающий вместе с WLM, обрабатывает соединения динамически. Где производить настройки в админ. консоли:

Серверы > Типы серверов > Серверы приложений WebSphere > имя-сервера, затем в разделе “Дополнительные параметры” нажмите “Свойства модуля Web-сервера”. Свойство “Максимальное число соединений с сервером приложений”.

ConnectTimeout

Означает «как долго plug-in будет ждать ответа от сервера, при попытке открыть сокет сервера приложений». Если потоки уже открыты и доступны серверу приложений, то plug-in будет использовать один из них. Если стоит значение «0», то тайм-аут никогда не случится, в этом случае срабатывает тайм-аут TCP соединения ОС, который не является идеальным.

Рекомендации:

  • Использовать небольшое положительное число, например 5 секунд.

Где производить настройки в админ. консоли:

Серверы > Типы серверов > Серверы приложений WebSphere > имя-сервера, затем в разделе “Дополнительные параметры” нажмите “Свойства модуля Web-сервера”. Свойство “Тайм-аут соединения”.

ServerIOTimeout

Означает «как долго plug-in будет ждать ответа от приложения». После того, как сокет будет открыт, plug-in направляет запрос серверу приложений. Приложение обрабатывает запрос и затем отдает клиенту ответ через plug-in.

Рекомендации:

  • Если приложение обрабатывает запросы быстро, то следует использовать небольшие значения ServerIOTimeout, такие как 60 сек
  • Если приложение ходит в БД и затрачивает больше времени на обработку, то необходимо использовать более высокие значения ServerIOTimeout, такие как 180 сек
  • Значение 0 означает, что тайм-аут чтения/записи не учитывается при работе, т.е. никогда не наступит
  • Положительное значение означает, что plug-in НЕ БУДЕТ помечать сервер «недоступным» (“down”), когда наступит тайм-аут и будет продолжать посылать в него запросы. Отрицательное значение означает, что plug-in БУДЕТ помечать сервер как «недоступен», по достижении тайм-аута и будет перенаправлять следующие запросы другому участнику кластера.
  • IBM рекомендует использовать значение -60

Где производить настройки в админ. консоли:

Серверы > Типы серверов > Серверы приложений WebSphere > имя-сервера, затем в разделе “Дополнительные параметры” нажмите “Свойства модуля Web-сервера”. Свойство “Тайм-аут чтения/записи”.

RetryInterval

Время, которое plug-in будет ждать перед повторной попыткой использовать сервер приложений, который был помечен как «недоступен» (“down”). Оптимальное значение этого параметра зависит от числа серверов приложений в кластере и значения свойства ServerIOTimeout.

Рекомендации:

  • Для вычисления максимального значения RetryInterval, использовать формулу: (количество серверов в кластере – 1)*(|ServerIOTimeout|)-1
  • Пример 1: два сервера в кластере, значение ServerIOTimeout=-60, тогда максимальное значение RetryInterval следует установить равным: (2-1)*(60)-1 = 59 секунд или меньше
  • Пример 2: четыре сервера в кластере, значение ServerIOTimeout=-60, тогда максимальное значение RetryInterval следует установить равным: (4-1)*(60)-1 = 179 секунд или меньше
  • Внимание: установка RetryInterval в значение выше рекомендуемого (вычисленного по формуле), может привести к тому что все сервера приложений в кластере будут помечены как «недоступен» (“down”)

Где производить настройки в админ. консоли: Серверы > Типы серверов > Web-серверы > имя-web-сервера > Параметры встраиваемого модуля > Маршрутизация запросов. Свойство “Периодичность опроса”.

Сессионные запросы (Affinity requests)

P.S.: Affinity – дословно: близость, сродство

Это запросы, содержащие куки сессии, т.е. (JSESSIONID). Запросы в рамках сессии будут обрабатываться на одном сервере приложений, независимо от LoadBalanceWeight. При использовании алгоритма Round Robin по умолчанию сессионные запросы не уменьшают вес участника кластера (IgnoreAffinityRequests=”true”). Это может привести к неравномерному распределению нагрузки между участниками кластера. Если использовать IgnoreAffinityRequests=”false”, то распределение нагрузки будет более равномерным, то есть работа алгоритма Round Robin будет более сбалансированной. При использовании алгоритма Random, сессионные запросы будут так же обрабатываться в одном сервере, но новые запросы будут распределяться случайным образом, и вес (LoadBalanceWeight) участников не учитывается.

Рекомендация:

  • В случае неравномерного распределения нагрузки между участниками кластера: для plig-in версии 6.1 и выше, установить свойство IgnoreAffinityRequests=”false”, для предыдущих версий plug-in следует использовать LoadBalance=”Random”

Где производить настройки в админ. консоли: Серверы > Типы серверов > Web-серверы > имя-web-сервера > Свойства модуля > затем в разделе “Дополнительные свойства” нажмите “Другие свойства”. Создайте новую переменную с именем IgnoreAffinityRequests и значением false.

Fail-over (отказоустойчивость)

Fail-over происходит когда plug-in помечает одного из участников кластера как «недоступен (marked “down”) и затем отправляет ожидающие запросы другому участнику кластера. Это может произойти, если plug-in не может установить новое соединение с сервером в течении ConnectTimeout. Или если plug-in уже направил запрос на сервер, но не получил ответа от приложения по истечении ServerIOTimeout. Когда plug-in помечает сервер как «недоступен», ожидающие запросы могут обрабатываться двумя способами:

  • До plug-in apar PM12112, отложенные запросы будут направлять другому участнику кластера (следующему по алгоритму)
  • После plug-in apar PM12112, plug-in будет случайно направлять отложенные запросы любому из участников кластера

Пока сервер помечен как «недоступен», ему не будут отправляться запросы. По прошествии RetryInterval, plug-in будет проверять, доступен ли сервер. Если это так, то флаг «недоступен» будет удален, а сервер будет использоваться снова.

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

Memory-to-Memory (M2M)

При использовании Memory-to-Memory (M2M) репликации сессий в сервере приложений свойство GetDWLMTable в plug-in должно быть изменено на “true”. Репликации Memory-to-Memory используют идентификаторы разделов (partition IDs), а не клоны идентификаторов (clone IDs). И если использовать GetDWLMTable=”false” (по умолчанию), это может привести к ошибкам в обработке сессий, affinity.

Рекомендации:

  • Важно установить GetDWLMTable=”true”, при использовании М2М репликации сессий.

Где производить настройки в админ. консоли: Серверы > Типы серверов > Web-серверы > имя-web-сервера > Свойства модуля (Plug-in properties) > затем в разделе “Дополнительные свойства” нажмите “Другие свойства”. Создайте новую переменную с именем GetDWLMTable и значением true.

Важно!

Каждый дочерний процесс httpd.exe имеет свой собственный экземпляр plug-in, загруженный в память. Динамическое изменение весов участников кластера не распространяется между экземплярами plug-in. В связи с эти может возникнуть ситуация, когда один экземпляр плагина присвоил участнику кластера вес 5, а другой экземпляр плагина пометил того же участника как «недоступен». Поэтому рекомендуется использовать один дочерний процесс веб-сервера с большим количеством нитей, т.е. числом клиентских соединений.

P.S: После сохранения настроек необходимо сгенерировать и пропагандировать плагин.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
Метки: , , , ,
Опубликовано в IBM HTTP Server & Plug-in, WebSphere Application Server

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: