Keep ALive for backend

[Kostya Alexandrov]

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 беременных женщин за месяц не рожают :)
>>     
>
> шутки не понял :-)
>
>   
Ошибся. Девять беременных женщин за месяц не родят.