Re: Ограничение соединений с backend

[Vladimir Latyshev]

Предположим, нагрузка на сервис колеблется от 5 до 30 запросов в сек. Запас
прочности к примеру 100. Если выше - поднимается la и сервера уходят в
думку, а клиенты - в ожидание. Последствия баннерной рекламы в соцсетях
могут превысить все ожидания. DOS атаки тоже никто не отменял. При
длительности в несколько часов времени среагировать другими способами может
не оказаться.
Вот и хотим пойти путем наименьшего зла.
Короче говоря, речь не о штатной нагрузке а о всплесках, которые весьма
вероятны. Закладываться на них горизонтальным масштабированием - дорого.

А медленные клиенты, это ж очевидно. 90% того, что идет через инет,
"медленные" по отношению к общению серверов между собой. А если речь о WAP,
то тем более.

16 июня 2009 г. 17:02 пользователь Sergej Kandyla <sk.paix at gmail.com>написал:

> Vladimir Latyshev пишет:
>
>> Представляю прекрасно. Если при большой нагрузке запрос выполняется 1
>> секунду, то 100 апачей, о которых я писал - это 100 запросов в секунду. Да,
>> это много, но не настолько, чтобы говорить, что такого не бывает ;) А
>> соломку надо стелить заранее.
>>
>
> подготовка - это хорошо ;)
> Но, есть такая индейская пословица:  "Лошадь сдохла - слезь"
>
> Если бекенд подает симптомы к умиранию, то его и нужно оптимизировать,
> кешировать, маштабировать.
> Попытка скрыть от клиентов service degradation - это все равно что попытка
> оживить дохлую лошадь.
>
> В конце концов о каких медленных клиентах шел разговор, если их обслуживает
> nginx ?
>
>
>
>> Кстати, в данный момент у нас срочно требуются " хорошие разработчики PHP"
>> в кол-ве 10 чел. По всей видимости, для разработки высоконагруженного
>> проекта. Кому интересно - пишите.
>>
>>
>>
>
> --
> Best wishes, Sergej Kandyla
> Всегда улыбайтесь жизни и жизнь всегда улыбнется вам!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090616/7c507d9c/attachment.html>