Вопросы Теги

Подсистема балансировки нагрузки Apache ограничивает с Tomcat по AJP

Защитите Ваш/wp-admin/каталог. Заблокируйте вниз/wp-admin/так, чтобы только определенные IP-адреса могли получить доступ к тому каталогу. Можно использовать .htaccess файл, в котором можно поместить непосредственно/wp-admin/.htaccess. Это - то, на что можно было быть похожим:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName “Access Control”
AuthType Basic
order deny,allow
deny from all
# whitelist home IP address
allow from 69.148.58.93
# whitelist work IP address
allow from 69.148.59.6
allow from 69.148.58.92
# IP while in Kentucky; delete when back
allow from 63.144.53.91

Josh

6
задан 27 March 2010 в 01:59
7 ответов

Решение для этой проблемы довольно просто:

добавьте к Proxypass:

BalancerMember ajp://10.176.201.9:8009 keepalive=On ttl=60

добавьте к Котам Server.xml:

Порт Connector = "8009" протокол = "AJP/1.3" redirectPort = "8443 connectionTimeout = "60000"

После того, как эти изменения, которыми все должно быть, хорошо работают :-)

7
ответ дан 3 December 2019 в 00:20

Учитывая, что журнал Apache иллюстрирует, что не может соединиться с Tomcat (из Вашего журнала ошибок), казалось бы, что это - приложение Tomcat, которое не может поддержать на высоком уровне.

Когда я работал sys администратором для веб-сайта Tomcat большого выхода, я заметил серьезные ограничения производительности, и они не были до ЦП, но проблем синхронизации между потоками или задержками запросов веб-сервиса бэкенда.

Последний был огромной проблемой, потому что популярный интерфейс Java HTTP ограничивает количество одновременных соединений с другим веб-сервером к 2 по умолчанию (когда я обнаружил эту отброшенную челюсть). См. http://hc.apache.org/httpclient-3.x/threading.html

Ваше веб-приложение называет какие-либо другие веб-сервисы?

1
ответ дан 3 December 2019 в 00:20

Похоже, что Apache получает тайм-аут соединения, соединяющийся с серверами в пуле, который заставляет это не мочь служить запросу. Ваше значение тайм-аута смотрит ОЧЕНЬ низкая, неустойчивая сетевая задержка, или даже страница, которая занимает немного дополнительного времени к сгенерированному, могла заставить сервер выпадать из пула. Я попробовал бы более высокий тайм-аут и значения повторной попытки и возможно более высокое значение ping.

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

Специализированное программное обеспечение прокси/стабилизатора, такое как сквид, могло бы также быть хорошим вариантом.

1
ответ дан 3 December 2019 в 00:20
  • 1
    Переключение на рабочий поток является определенно опцией, но я хотел бы выяснить, какова первопричина 503 с. –  Peter Sankauskas 29 March 2010 в 19:24
  • 2
    Смотря на Ваше сообщение более тщательно, похоже, что Apache получает тайм-аут соединения, соединяющийся с серверами в пуле, который заставляет это не мочь служить запросу. Ваше значение тайм-аута смотрит ОЧЕНЬ низкая, неустойчивая сетевая задержка, или даже страница, которая занимает немного дополнительного времени к сгенерированному, могла заставить сервер выпадать из пула. Я попробовал бы более высокий тайм-аут и значения повторной попытки и возможно более высокое значение ping. I' ve обновил мой ответ для содержания этих предложений. –  Eric 31 March 2010 в 05:01

Ваши экземпляры кота зашли в тупик? Я засвидетельствовал два больших корпоративных (различные компании), проекты кота страдают от мертвой блокировки - каждый был вызван более старой версией сторонней пользовавшейся библиотеки.

Можно ли все еще соединиться непосредственно с экземпляром кота локально? Это:

telnet localhost 8080

Затем тип:

GET / HTTP/1.0\n
\n

(где \n относится к <ввести> ключу).

Если не затем казалось бы, что Ваш экземпляр кота умер или зашел в тупик. Если это зашло в тупик затем, пора получить дамп стека Вашего кота экземпляр Java с помощью jstack программа (с PID кота программа Java).

0
ответ дан 3 December 2019 в 00:20
  • 1
    Да большинство времени серверы Tomcat прекрасны и делают то, что они, предполагают к. Я задаюсь вопросом, существует ли некоторый предел конфигурации Apache или Debian что это поражаемый. –  Peter Sankauskas 29 March 2010 в 19:23

ПЕРВЕНСТВО,

Я не видел, что значение тайм-аута на Apache зарегистрировало Вас вставляемый. Если это 300, попытайтесь изменить его на 1200. У нас была та же проблема, и изменение тайм-аута на Apache httpd.conf файл от 300 до 1 200 зафиксировало ее.

0
ответ дан 3 December 2019 в 00:20

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

0
ответ дан 3 December 2019 в 00:20

Давайте ответим на этот вопрос, 6 лет спустя = D 

retry=1 timeout=1

В этом проблема. таймаут и повтор слишком короткие.

Тайм-аут будет считать серверы мертвыми, если они не ответят в течение 1 секунды. Это слишком мало для обработки некоторых запросов (особенно, если вы выполняете нагрузочное тестирование при 500 запросов / с).

Обратите внимание, что как только сервер выходит из строя, 2 оставшихся сервера получают + 50% запросов, и время их ответа увеличивается значительно, до такой степени, что они, вероятно, также мгновенно отключатся. Типичный каскадный сбой.

Вы получаете 503 «Служба недоступна», потому что все серверы считаются неработающими Apache, потому что они не отвечают достаточно быстро под нагрузкой, потому что ваш тайм-аут слишком короткий.

Удалите обе настройки. Вообще говоря, НИКОГДА не устанавливайте тайм-аут менее 5 секунд где-либо.

0
ответ дан 3 December 2019 в 00:20

Теги

Похожие вопросы