On Wed, 26 Jun 2002, Alexey Zvyagin wrote:
> Сейчас фронтенд держит в базилоках процесс фронтенда, если 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
Неправильный опыт. Для бизилоков используется тот же md5, что и для
ключа в кэше, то есть, полный URL и, возможно, специально указанные куки.
> не закончится. Для нового 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 - но это не так гибко.
Бизилоки нужны для того, чтобы не дёргать бэкенд ещё раз, если точно такой
же запрос уже обрабатывается и его результатом можно будет воспользоваться.
Использовать бизилоки для запросов, у которых в ответе стоит
"Cache-Control: no-cache" можно, но бессмысленно. Гораздо эффективнее
ставить их в очередь не с помощью бизилоков, а с помощью listen backlog queue.
Игорь Сысоев
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
