Предположим, нагрузка на сервис колеблется от 5 до 30 запросов в сек. Запас прочности к примеру 100. Если выше - поднимается la и сервера уходят в думку, а клиенты - в ожидание. Последствия баннерной рекламы в соцсетях могут превысить все ожидания. DOS атаки тоже никто не отменял. При длительности в несколько часов времени среагировать другими способами может не оказаться.
Вот и хотим пойти путем наименьшего зла. Короче говоря, речь не о штатной нагрузке а о всплесках, которые весьма вероятны. Закладываться на них горизонтальным масштабированием - дорого.
А медленные клиенты, это ж очевидно. 90% того, что идет через инет, "медленные" по отношению к общению серверов между собой. А если речь о WAP, то тем более.
16 июня 2009 г. 17:02 пользователь Sergej Kandyla <sk.paix@xxxxxxxxx> написал:
Vladimir Latyshev пишет:
Представляю прекрасно. Если при большой нагрузке запрос выполняется 1 секунду, то 100 апачей, о которых я писал - это 100 запросов в секунду. Да, это много, но не настолько, чтобы говорить, что такого не бывает ;) А соломку надо стелить заранее.
подготовка - это хорошо ;)
Но, есть такая индейская пословица: "Лошадь сдохла - слезь"
Если бекенд подает симптомы к умиранию, то его и нужно оптимизировать, кешировать, маштабировать.
Попытка скрыть от клиентов service degradation - это все равно что попытка оживить дохлую лошадь.
В конце концов о каких медленных клиентах шел разговор, если их обслуживает nginx ?
Кстати, в данный момент у нас срочно требуются " хорошие разработчики PHP" в кол-ве 10 чел. По всей видимости, для разработки высоконагруженного проекта. Кому интересно - пишите.
--
Best wishes, Sergej Kandyla
Всегда улыбайтесь жизни и жизнь всегда улыбнется вам!
