ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mod_accel MC & MW




Добрый день!

>>Ситуация: [MC=1,MW=32,MP=P]. Медленный backend.
>>При более чем одном одновременном запросе получаем 503 на "лишние" запросы. 
>То 
>>есть запросы в очередь на ожидание освобождения backend не встают...
> 
> 
> [...]
> 
> 
>>(запросы не отваливаются с 503 а ждут освобождения backend и потом успешно 
>>отрабатываются), но вероятно это не совсем корректный патч...
> 
> 
> MW учитывается только в случае, если ответ может быть в принципе кэшируем.
> То есть, в данной реализации MW не может использоваться как средство
> буферизации некэшируемых запросов. Это только средство ограничить число
> запросов, ждущих обновления или получения кэшируемого ответа.
 >
> Буферизацию можно сделать двумя способами.
> 
> 1. Сделать так, чтобы на этапе отправки запроса бэкенду он был в принципе
> кэшируем, а в ответе выставлять, например, "X-Accel-Expires: 0".
> Тогда MW будет учитываться.

В данной ситуации все запросы, которые выдает backend, кешируемы (и реально 
кешируются)... Стоит AccelDefaultExpire, backend ничего про кеширование не 
говорит. То есть так: "MISS/-/0/C 200/ADE/3600 10 3/2065/2065"

То есть не учитывается MW, к сожалению, (что в принципе из фрагментов кода 
видно)... Но охотно верю, что что-то не понимаю, поскольку странно, что на это 
до сих пор никто не наступил. :)

> 2. Уменьшить число бэкендов и увеличить listen backlog в Апаче и ядре.
> Поставить MC=32. В этом случае буфером будет ядерная listen queue.

Тут нужно, чтобы было MC=1 (условная ситуация, что backend не умеет хорошо 
обрабатывать несколько запросов одновременно :).

P.S. Безотносительно: а про то, что в случае, если ответ не должен 
кешироваться, 
ограничения работают иначе, думаю имеет смысл написать и вообще видоизменить 
текст, чтобы не было неоднозначных трактовок. :)

WBR, MoKo



 




Copyright © Lexa Software, 1996-2009.