Re: Keep ALive for backend

[Kostya Alexandrov <koticka@xxxxxxx>]

Alexey Rymonin wrote:
> 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 исполняющихся
> > одновременно запросов.
> >     
> Ну на уровне БД резкий наплыв желающих вылонить свой запрос легко
> ограничеваются максимальным кол-вом соединений в пуле, и как следсвие,
> неудачники получают красивый отказ в обслуживании...
>
>   
Это был простой пример, на уровне БД пула соединений нет, не стоит 
путать технологии типа Oracle MTS/Shared Server с пулом конектов. Об 
отказе никто не говорит. Отказ это караз легко организовать. Реч о 
пулировании.
> > Тоже самое может касаться и бекенда на php, jsp....
> >     
> Я вообще всегда считал что подвесить на борьбу за ресурсы php, jsp,
> perl и что-либо еще, которые не выполняют выборок из БД или другой
> жесткой работы с HDD практически не возможно. Сейчас уже процессорное
> время,ровно как и память, не является дифицитным ресурсом (ну ясное дело по 
> сравнению с
> фаловыми ресурсами).
>   
Глупости. А зачем придуманы пулы экзекуторов, очереди и т.п.
Т.к. у нас более мощные камни, мы лучше умеем их озадачивать.
> Да и по моему фроненду принимать решение об отказе в обслуживании
> как-то не доконца правильно, поскольку эта возможность будет позволять
> вешать заплатки на системы, обходя неодходимость
> концептуального/структурного решения проблемы.
> Просто по моему, отказ в обслуживании по какой либо причине для
> открытых инф. систем - это ошибка...
> Но, всегда существуют еще заказщики, менеджеры, исторические факты и
> так далее, которые заставляют лепить заплатки.
>
>   
Теоретически прав на 100%. Реально в жизни - тебе падает на саппорт 
легаси систма с тысячами пользователей и десятками мегабайт кода. Вот 
тут и расскажи что была неверная концепция. Оптять же,
повторюсь об отказе в обслуживании никто не говорит. Реч идет о том чтоб 
недопустить "излишней параллелизации".
> > 6 беременных женщин за месяц не рожают :)
> >     
> шутки не понял :-)
>
>   
Ошибся. Девять беременных женщин за месяц не родят.