ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


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


  ПРОГРАММЫ 



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












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

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

Re[2]: Keep ALive for backend



Hello Kostya,

Friday, November 9, 2007, 1:46:33 PM, you wrote:

> Ну так веся конитель только потому что "юзать java.io смерти подобно... "
> Алексей, Вы переходите в более философский вопрос.
> Сам посебе такой метод обслуживания клиентов (http запрос каждые 2 сек)
> является
> полным идиотизмом, как и само использование weblogic для нашего вида 
> задач. Внезависимости от нативные либо бинарные библиотеки используются.
> Ни nio, ни нативный конектор (Вы говорите про APR к токату) тут 
> применить влоб нельзя, иначе бы уже применили. Как раз сейчас и делаем
> "свой http" на apache mina. Но это тоже временное решение.

> В любом случае, мне кажется, что какой бы нибыл бекенд, конекты лучше 
> всего пулировать,
> и если есть возможность иметь определенное количество persistent 
> соединений, то это будет
> очень востребовано. Ни каждый бекенд может выдержать резкий наплыв запросов.

> Например случай с базой данных, если бекенд формирует какие либо отчеты
> и т.п. и по какой либо
> причине не может обойтись фиксировааным пулом. Абстрактно ситуация может
> быть такой:
> - 10 активных запросов, каждый работает 1 сек.
> - 50 - каждый работает 2 секунды
> - 100 каждый работает по 5 минут. Ресурсы закончились, дикая конкуренция
> за io и процессор приемущественно занят переключением контекста....

> В этом случае выгоднее иметь очередь и только 50 исполняющихся
> одновременно запросов.

Ну на уровне БД резкий наплыв желающих вылонить свой запрос легко
ограничеваются максимальным кол-вом соединений в пуле, и как следсвие,
неудачники получают красивый отказ в обслуживании...

> Тоже самое может касаться и бекенда на php, jsp....

Я вообще всегда считал что подвесить на борьбу за ресурсы php, jsp,
perl и что-либо еще, которые не выполняют выборок из БД или другой
жесткой работы с HDD практически не возможно. Сейчас уже процессорное
время,ровно как и память, не является дифицитным ресурсом (ну ясное дело по 
сравнению с
фаловыми ресурсами).
Да и по моему фроненду принимать решение об отказе в обслуживании
как-то не доконца правильно, поскольку эта возможность будет позволять
вешать заплатки на системы, обходя неодходимость
концептуального/структурного решения проблемы.
Просто по моему, отказ в обслуживании по какой либо причине для
открытых инф. систем - это ошибка...
Но, всегда существуют еще заказщики, менеджеры, исторические факты и
так далее, которые заставляют лепить заплатки.

> 6 беременных женщин за месяц не рожают :)

шутки не понял :-)

-- 
Best regards,
 Alexey                            mailto:x-phoenix@xxxxxxx




 




Copyright © Lexa Software, 1996-2009.