Здравствуйте, Игорь!
> Прежде всего хочу заметить, что MC и MW разрабатывались для того,
> чтобы загруженный бэкенд не забрал на себя все процессы фронтенда,
> а не для того, чтобы ограничивать число процессов бэкенда. Число бэкендов
> легко ограничивается на самом бэкенде.
>
> Если бэкенд не может обработать больше 30 соединений одновременно,
> то ему нужно поставить MaxClients 30 и всё.
> В этом случае запросы фронтенда будут становиться в очередь,
> длина которой равна backlog'у listen() на бэкенде.
> Если фронтенд обслуживает ещё что-нибудь кроме этого бэкенда, то
> MC можно поставить 500, для того, чтобы только эта часть запросов
> ушла к бэкенду и осела в его backlog'е.
> Backlog можно увеличить:
> ListenBacklog 1000
> ну и в OS его подкрутить, если он меньше нужного значения.
Спасибо большое за ответ! Я не знал про BackLog
Но вот подумал, и хочу сделать предложение по одному параметру. Возможно он
лишний, но мне пока так не кажется.
Сейчас фронтенд держит в базилоках процесс фронтенда, если URL в принципе
кешируемый, но в кеше ответа нет, а уже один из таких урлов в запросе к
бекенду. Но я часто наблюдаю ситуацию, что кол-во коннектов к бекенду не
дошло до MC, а в базилоках такие запросы крутятся и ждут того единственного,
что в обработке. Есть предложение такого рода. Ввести такой параметр, как
счетчик-лимит для одного и того же URL, который крутится в базилоке. Если
лимит по счетчику для такого URL не достигнут и кол-во коннектов к бекенду
не превышено, то делается запрос к бекенду, и в базилок такой запрос не
кладется. Вот пример:
Предположим первый параметр AccelBusyLock например 10, и некий мифический
параметр-счетчик - 3
1. Поступил запрос типа /redir.cgi?s=123, ответа в кеше нет, делается запрос
к бекенду. Ставится счетчик для такого URL, что он на обработке к бекенду и
в одном экземпляре
2. ответ еще не пришел от бекенда, предположим прошла секунда, но поступает
новый запрос /redir.cgi?s=123 или /redir.cgi?s=456 (как я понял из опыта
работы, для аргумента MD5 используется URL без QUERY_STRING). Если брать в
расчет mod_accel 1.0.20, то он будет ждать 10 секунд, пока первый /redir.cgi
не закончится. Для нового mod_accel предлагается посмотреть в счетчик URL-а
(или хеша MD5 для такого запроса), если он не превысил 3 (параметр-счетчик)
и кол-во коннектов к бекенду тоже не превышено или не равно, то для
/redir.cgi увеличиваем счетчик и делаем новый запрос к бекенду, не кладя его
в базилок. Таким образом, счетчик для запроса /redir.cgi равен уже двум.
3. Поступает новый запрос на /redir.cgi, смотрим что пока на redir.cgi
счетчик равен 2, увеличиваем его, снова делаем к бекенду запрос, если MC не
достигло. Если MC достигло, тогда кладем в базилок и поступаем как поступаем
и сейчас, а счетчик не увеличиваем.
То есть сегодняшняя версия accel подобно "новая версии accel" с
параметром-счетчиком по default 1. Но хотелось бы, чтобы мы могли его
поставить скажем в 3-10, если нужно.
Я предлагаю это потому, что сейчас модель базилоков не позволяет делать
более одного запроса такого-же к бекенду, пока не истекут таймауты, хотя
часто получается что кол-во коннектов с бекендом не достигло MC. И
получается, что пользователь ждет реакции сервера, хотя он мог бы
использовать все ресурсы сервера, так как бекенд свободен (при лимите MC=15
я часто вижу что 12 процесов бекенда, когда MC=25 и большие таймауты у
базилоков, то также часто 11-12 процессов бекенда). И ListenBacklog тут не
поможет, как я понимаю, разве что ставить маленькие параметры первый и
второй в AccelBusyLock - но это не так гибко.
>
>
> Игорь Сысоев
> http://sysoev.ru
С уважением, Алексей
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =