Добрый день, Игорь!
> > Игорь, базилоки работают, по крайней мере ограничение работает :)
> > Я поставил MC=40, и когда вдруг снова резко возросло кол-во процессов
> > бекенда, их было иногда 59. Хотя бекенд настроен, чтобы было 160
максимум.
> > На бекенде у меня стоит
> > MinSpareServers 3
> > MaxSpareServers 5
> > то есть 59-5 = 54 процесса было точно занято. Наверное, это из-за того
что
> > AccelTimeout у меня пока 70 секунд. Скоро поставлю до 10 минут, как вы
> > посоветовали. Тока вопрос - значит ли это что конечному пользователю при
> > занятости бекенда придется ждать отлики от сервера 70 сек. или 10 минут,
> > если я сделаю такую опцию?
>
> Значит, так. У нас есть объективная реальность, данная нам в ощущениях,
> в виде бэкенда, которого иногда колбасит. Наша задача - не допустить
> этого состояния или хотя бы уменьшить его продолжительность.
>
> Если мы зададим небольшой таймаут, то пользователь увидит 504,
> а один процесс бэкенда будет продолжать колбаситься. Ничто не мешает
> пользователю послать новый запрос фронтенду и соответсвенно бэкенду.
> Бэкенду от этого будет лишь хуже.
>
> Если зададим большой таймает, то пользователь ничего не увидит,
> один процесс бэкенда будет колбаситься, а один процесс фронтенда
> будет его ждать. Пользователь повторяет запрос. Если число
> ждущих или соединённых фронтендов достигло максимума, то пользователь
> сразу получит 503.
Вы сказали "Если число ждущих или соединённых фронтендов достигло
максимума...". А вообще, возможно, чтобы пользователь получал 503 ошибку не
тогда когда MC дошло до своего максимума или MW до своего, а тока тогда,
когда MW дошло до максимума?
Вот пример: у меня бекенд использует SQL, я не могу поставить MC более 25
например, потому что буду знать точно, что будет больше persistent коннектов
к базе, если бекендов будет более 30, а значит к SQL будет много в паралелль
очередей, и ресурсы быстро будут истощятся. Поэтому мне хотелось бы, чтобы
бекендов всегда было около 30. Но если я ставлю MC=35 например, то как тока
коннектов 35, фронтенд сразу отдает 503 клиенту, несмотря на то, что может
быть MW не достигло скажем своего максимума в 500, к примеру (я вижу, что
фронтендов у меня обычно 1000, хотя и 2000 мог бы сервак потянуть, так как
память сильно шарится...). Вот если бы фронтенд дойдя до пика в 35 коннектов
к бекенду, не отдавал 503 пока не достигнет кол-ва процессов в базилоках до
500, мне кажется, было бы лучше, по крайней в той ситуации, когда 90%
запросов - это динамические страницы с Pragma: no-cache и многие документы
отсутсвуют в кеше. Я вижу, что бекенд мог бы разрулить больше запросов, так
как чаще он недогружен, но вот фронтенд частенько сыпет в access.log 503
ошибку клиенту.
Уже проапгрейдил mod_accel до 1.0.20 (особых изменений не заметил), пробовал
менять многие параметры, сильно оптимизировал SQL команды и бекенд уже не
так нагружен. Но вот большинство запросов, например:
/redir.cgi?quesry_string
У меня летят на 503 ошибку, и все потому что:
1. Они не кешируемы, а значит многие прелести кеширования в устареванием
ответов бесполезны
2. Сервер бы мог обработать в параллель условно говоря, несколько
/redir.cgi?quesry_string, для этого я ставлю первые два параметра
AccelBusyLock примерно в 2-3 секунды, и это помогает, но вот третий в
параллель процесс мог бы подождать в базилоке, но как только коннектов к
бекенду становится ровно как MC, так пользоатель видит 503. Тут все
работать, как и задумано у вас и как описано в доке.
3. Без busylocks работает все хуже гораздо, но только потому, что фронтенд
не скупится на соединения в бекендом. А много соединений уже просто
расшатывают SQL по одновременным UPDATE, DELETE и SELECT командам. Когда
коннектов тока около 20-30 то все работает шустро.
4. Хотелось бы, чтобы фронтенд в такой ситуации тоже ограничивал по
соединениям бекенд, но как я уже сказал, выдавал 503 ошибку тока когда
достигло MW своего максимума, а MC тоже ограничивалось, но при максимуме
процессы ждали в базилоках до MW пика.
С уважением, Алексей
> Игорь Сысоев
>
>
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
