Re: [apache-talk] Веб-акселлератор

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Fri, 21 Dec 2001, Дмитрий wrote:

> Возможно оффтопик, но все ж.
> Что бы поставить в качестве веб-акселлератора?
> Цель: снизить нагрузку на сервер, в частности на mySQL. Ну и всякие
> там PHP, Perl тоже свою лепту вносят на общую загрузку сервера.
> Squid? Есть ли альтернатива squid'у?
> И вообще стоит ли связываться с этим?

Акселератор используется для решения следущих проблем.

1. Буферизация медленного клиента.

Она нужна, если используется тяжёлый бэкенд, например, mod_perl,
обыкновенно занимающий десятки мегобайт. Или же каждый бэкенд держит
соединение с тяжёлой базой данных, типа Oracle или PostgreSQL.
Много таких процессов не запустишь.

Предположим, mod_perl создаёт ответ в среднем за 0.2 секунды. При размере
в 20К ответ сразу же попадёт в буфер ядра и за 6-7 секунд уйдёт
к модемному клиенту (3K/s). Но mod_perl будет занят ещё 2 секунды в
lingering_close(). За это время он мог бы обслужить ещё 10 запросов.
При передаче ответов больше, чем размер буфера ядра, mod_perl будет
простаивать на время передачи части ответа, превышающей размер буфера ядра,
плюс 2 секунды в lingering_close().

При использования правильного акселератора (mod_proxy к ним не относится)
такого не происходит и mod_perl в lingering_close() не ждёт.

Второй момент - это upload данных. Тут никакие буфера ядра вообще
не помогут. Если модемный клиент вливает 20К, то mod_perl будет
занят 6-7 секунд.

2. Кэширование ответов.

Ну, тут всё понятно. Применяется, когда время генерации достаточно
большое или же для этого используется много ресурсов.

Некоторые возможности mod_accel:

Busy lock'и позволяют передавать бэкенду только один запрос
из нескольких одинаковых. Все остальные процессы в течение заданного
времени ждут получения этого ответа.

Кэширование с учётом кук. Если сайт можно кастомизировать
с помощью кук, то есть вероятность, что большинство пользователей этой
кастомизацией не воспользуются, то есть, для них ответы можно было
бы кэшировать, если бы не куки некоторых пользователей.
Кэширование с учётом кук позволяет решить эту проблему.

3. Распределение нагрузки и отказоустойчивость.

mod_accel может работать с несколькими бэкендами, балансируемыми
через DNS. При невозможности соединения, таймауте или ответом
с кодом 5xx, mod_accel переходит к следущему бэкенду. Но информация
о недоступности бэкенда не учитывается при следущих соединениях.

Игорь Сысоев

=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =