Пара гвоздей в гроб html browser-based приложений

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 21:21

ЗЫ
Я не призывал отказаться от сессий
А наоборот хотел чтобы каждой Session соответствовал thread, и система не была бы stateless
Но мелгомягкие нашли другое решение

f_evgeny · Post by **f_evgeny** » 27 Apr 2004 21:39

Dmitry67 wrote:Согласен с Seryi

2 f_evgeny
Мы делаем... грубо говоря жто очень специализированный редактор докукментов сложной структуры
Каждая маленткое поле имеет историю изменений, список подписей итд
А интерактивность работы с редактором сами понимаете какая

И какие клиенты? Браузеры, или самописные приложения. Протокол обмена основан на HTTP?

Palych · Post by **Palych** » 27 Apr 2004 21:45

Stateless vs. Stateful - дудочка и кувшинчик.
HTTP благодаря своей stateless природе лежит в основе идеи Веб-приложений, главное преимущество которых - масштабируемость.
Если вынести логику в "апплет" - от stateless запросов никуда не деться, иначе многие вещи просто невозможно реализовать. Другое дело что логику связанную текущей сессии можно вынести на клиента. Однако я сумлеваюсь что сессии на сервере никогда не понадобятся...
Вобщем - реальные приложения построенные по такой архитектуре рискуют быть гораздо уродливее современных Веб-приложений...

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 21:45

Дык если бы самописные приложения то проблем бы небыло бы
Клиент - IE

Sergey___K · Post by **Sergey___K** » 27 Apr 2004 21:48

@@SPID

А в чем проблемы с @@SPID?

Palych · Post by **Palych** » 27 Apr 2004 21:50

Dmitry67 wrote:ЗЫ
Я не призывал отказаться от сессий
А наоборот хотел чтобы каждой Session соответствовал thread, и система не была бы stateless
Но мелгомягкие нашли другое решение

I chto etot thread dolzhen delat'?
Mozhno opisat' v obschih chertah?

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 21:55

Palych wrote:Stateless vs. Stateful - дудочка и кувшинчик.
HTTP благодаря своей stateless природе лежит в основе идеи Веб-приложений, главное преимущество которых - масштабируемость.
Если вынести логику в "апплет" - от stateless запросов никуда не деться, иначе многие вещи просто невозможно реализовать. Другое дело что логику связанную текущей сессии можно вынести на клиента. Однако я сумлеваюсь что сессии на сервере никогда не понадобятся...
Вобщем - реальные приложения построенные по такой архитектуре рискуют быть гораздо уродливее современных Веб-приложений...

Чтото мы совсем не понимаем друг друга

1. В чем Вы видите не масштабируемость stateful приложений ? В том что на кажлую коннекцию не создать thread ? Сколько занимает thread ? Сколько поместится threads на 4Gb сервере ? Сколько поместится на 64bit сервере ?

2. В чем заключается масштабируемость stateless приложений ? В том что на сервере экономится память но 99%CPU идет на сериализацию десериализацию и работу с viewstate ? КПД как у паровоза, даже хуже. И потом что делают - правильно, ставят в ряд много таких серверов. При том что на самом деле с такой задачей играючи справился бы один

Опят таки не берем экстремумы в виде google.Мы брем системы ERP фирмы, webmail клиент exchange итд.

3. Наконец еще раз
Я не против сессий на клиенте
наоборот я считаю что огни недостаточно выражены и я считаю что на каждую сессию должен быть stateful thread

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 21:59

Sergey___K wrote:
@@SPID
А в чем проблемы с @@SPID?

Иногда применяется технология квазивременных таблиц с полем N=@@spid
Это только один пример
@@spid часто используется для идентификации
Проблема в том что в stateless системе @@spid вашей коннекции на самом деле непредсказуемо меняется при каждом клике

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 22:02

Palych wrote:
Dmitry67 wrote:ЗЫ
Я не призывал отказаться от сессий
А наоборот хотел чтобы каждой Session соответствовал thread, и система не была бы stateless
Но мелгомягкие нашли другое решение

I chto etot thread dolzhen delat'?
Mozhno opisat' v obschih chertah?

Вот вы начали сессию
Запустился thread
Вы открыли в нем коннекцию
так как все объекты не разрушаются после каждого клика то коннекция не закрывается и существует все время жизни сессии
Далее все переменные, списки, обхекты так и хранятся
Вот и все
Как в нормальных windows приложениях

Palych · Post by **Palych** » 27 Apr 2004 22:17

to Dmitry67
1. Stateful resource trebuet mnogo telodvizhenij chtoby podderzhivat' state na servere i kliente. Osobenno v sluchae udallennogo soedineniya. K tomuzhe pri rabote v clustere prihoditsya libo privyazyvat' usera k konkretnomu serveru, libo peredavat' state po provodam.
2. U nas bol'shinstvo specoborudovaniya dopuskaet 1(odno) soedinenie. Nekotorye - 5. Tut masshtabiruemost' dostigaetsya za schet togo chto ne vse 6000 klientov lomyatsya na odin apparat.
serialization/deserialization v dannom sluchae nuzhna ne potomu chto Stateless, a potomu chto Remote.

2.1. Zadach gde bez clusters ne obojtis' ne tak malo. Von Privet i tot rasshiryaetsya...

3. Ya vse zhe ne ponimayu chto znachit Stateful Thread...

Strannik223 · Post by **Strannik223** » 27 Apr 2004 22:18

Проблемы statefull:

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

2. Большое количество клиентов быстро истощат память сервера своими данными. И не надо считать сколько памяти занимает поток, не много. А вот данных клиент может держать на сервере вобщем случае неопределенный объем. Множим количество клиентов на размер состояния, и получаем полную неопределеннось в потребности сервера в памяти.

2. Клиент может долгое время оставатся бездействующим занимая память на сервере своими данными.

3. Оно не масштабируемо. Сложно построить server farm. А утверждение о том что один сервер справится с любой нагрузкой...
Может сейчас и справится, а через год?

Sergey___K · Post by **Sergey___K** » 27 Apr 2004 22:20

Проблема в том что в stateless системе @@spid вашей коннекции на самом деле непредсказуемо меняется при каждом клике

@@SPID будет меняться независимо от stateless ваша система или нет.
Возьмите создайте connection (ADO) и создайте три command на этот connection, асинхронно запустите command-ы. Гляньте @@SPID. Они будут разными. @@SPID имеет смысл только в одном процессе. Если ваши три command будут каждый запускать развесистую и ленивую хранимую процедуру, то в пределах процесса, исполняющего одну вашу процедуру, (и, значит, этой процедуры), @@SPID не изменится.

Palych · Post by **Palych** » 27 Apr 2004 22:22

Dmitry67 wrote:Вот вы начали сессию
Запустился thread
Вы открыли в нем коннекцию
так как все объекты не разрушаются после каждого клика то коннекция не закрывается и существует все время жизни сессии
Далее все переменные, списки, обхекты так и хранятся
Вот и все
Как в нормальных windows приложениях

"Я так и думал!"(c)
Sorry.

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 22:24

Palych wrote:to Dmitry67
1. Stateful resource trebuet mnogo telodvizhenij chtoby podderzhivat' state na servere i kliente. Osobenno v sluchae udallennogo soedineniya. K tomuzhe pri rabote v clustere prihoditsya libo privyazyvat' usera k konkretnomu serveru, libo peredavat' state po provodam.
2. U nas bol'shinstvo specoborudovaniya dopuskaet 1(odno) soedinenie. Nekotorye - 5. Tut masshtabiruemost' dostigaetsya za schet togo chto ne vse 6000 klientov lomyatsya na odin apparat.
serialization/deserialization v dannom sluchae nuzhna ne potomu chto Stateless, a potomu chto Remote.

2.1. Zadach gde bez clusters ne obojtis' ne tak malo. Von Privet i tot rasshiryaetsya...

3. Ya vse zhe ne ponimayu chto znachit Stateful Thread...

1. Видимо у Вас замылился глаз
State на клиенте НЕ НУЖЕН

Как бы объяснить
Знаете как работает X11 ?
Запускается аппликация (thread), которая по TCPIP рисует на удаленном экране
накакого понятия state вообще нет
Теперь представьте что всемто протокола X11 аппликация 'рисует' с помощью HTML

То есть thread/аппликация ведет свою сессию от начала и до конца

Gennadiy · Post by **Gennadiy** » 27 Apr 2004 22:28

Dmitry67 wrote:Дык если бы самописные приложения то проблем бы небыло бы
Клиент - IE

Мы пару лет назад делали такого киента. Полноценный statefull клиент, работающий в IE и Netscape. Есть такая технология ActiveX (для Нетшкафа - plugin-s).
Был полноценный state на киенте. Плюс был state на сервере (на каждого клиента свой - маштабировалось прекрасно). Никакого HTML програмирования ублюдочных клиентских скриптов. Rich GUI интерфейс (realtime updates, графика, docking windows, никаких "вперед/назад"). Честный HTTP для прохождения прокси и фаерволов.
7000 клиентов, клиентская часть поддерживала до 1000 обменов в секунду, сервера до 1 млн меседжей в секунду.
Так что все можно было и раньше сделать. Не без усилий конечно.

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 22:31

Strannik223 wrote:Проблемы statefull:

1. Ни клиент ни сервер могут быть не в состоянии определить что другой из них закрыл сессию. Например из за недоступности сети.

2. Большое количество клиентов быстро истощат память сервера своими данными. И не надо считать сколько памяти занимает поток, не много. А вот данных клиент может держать на сервере вобщем случае неопределенный объем. Множим количество клиентов на размер состояния, и получаем полную неопределеннось в потребности сервера в памяти.

3. Клиент может долгое время оставатся бездействующим занимая память на сервере своими данными.

4. Оно не масштабируемо. Сложно построить server farm. А утверждение о том что один сервер справится с любой нагрузкой...
Может сейчас и справится, а через год?

1. А как жто делается сейчас ? Примитивный timeout, и все
2. Нет. я как раз потребую цифр
Практика моей работы показывает что перовым истощается CPU на сериализации а не память
3. Система виртуальной памяти автоматически (и на пааратном уровне) решает эту проблему
4. Почему ? Вы можете поставить в ряд несколько серверов. Да, коннекция не может перепрыгнуть с сервера на сервер. Ну так для https она и так не может перепрыгнуть

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 22:34

Sergey___K wrote:
Проблема в том что в stateless системе @@spid вашей коннекции на самом деле непредсказуемо меняется при каждом клике
@@SPID будет меняться независимо от stateless ваша система или нет.
Возьмите создайте connection (ADO) и создайте три command на этот connection, асинхронно запустите command-ы. Гляньте @@SPID. Они будут разными. @@SPID имеет смысл только в одном процессе. Если ваши три command будут каждый запускать развесистую и ленивую хранимую процедуру, то в пределах процесса, исполняющего одну вашу процедуру, (и, значит, этой процедуры), @@SPID не изменится.

@@spid меняется если коннекция переоткрывается
В Winforms я могу открыть коннекцию и если она не рвется то держать ее
В web коннекция переоткрывается при каждом клике.

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 22:37

Gennadiy wrote:Мы пару лет назад делали такого киента. Полноценный statefull клиент, работающий в IE и Netscape. Есть такая технология ActiveX (для Нетшкафа - plugin-s).
Честный HTTP для прохождения прокси и фаерволов.
7000 клиентов, клиентская часть поддерживала до 1000 обменов в секунду, сервера до 1 млн меседжей в секунду.
Так что все можно было и раньше сделать. Не без усилий конечно.

Думаю это был не IIS и не .Net

Sergey___K · Post by **Sergey___K** » 27 Apr 2004 22:39

@@spid меняется если коннекция переоткрывается
В Winforms я могу открыть коннекцию и если она не рвется то держать ее
В web коннекция переоткрывается при каждом клике.

Еще раз, у вас @@SPID может меняться без переоткрытия коннекции.
(в WinForms, очевидно тоже, я пробовал простой ADO 2.7) на одну коннекцию у кадого ассинхронного запроса будет свой @@SPID.

Gennadiy · Post by **Gennadiy** » 27 Apr 2004 22:41

Dmitry67 wrote:
Gennadiy wrote:Мы пару лет назад делали такого киента. Полноценный statefull клиент, работающий в IE и Netscape. Есть такая технология ActiveX (для Нетшкафа - plugin-s).
Честный HTTP для прохождения прокси и фаерволов.
7000 клиентов, клиентская часть поддерживала до 1000 обменов в секунду, сервера до 1 млн меседжей в секунду.
Так что все можно было и раньше сделать. Не без усилий конечно.

Думаю это был не IIS и не .Net

Нет - это были WebLogic, Netscape Enterprise server, Oracle и Java на сервере и Delphi на клиенте.

Dmitry67 · Post by **Dmitry67** » 27 Apr 2004 23:20

Sergey___K wrote:
@@spid меняется если коннекция переоткрывается
В Winforms я могу открыть коннекцию и если она не рвется то держать ее
В web коннекция переоткрывается при каждом клике.
Еще раз, у вас @@SPID может меняться без переоткрытия коннекции.
(в WinForms, очевидно тоже, я пробовал простой ADO 2.7) на одну коннекцию у кадого ассинхронного запроса будет свой @@SPID.

Значит для асинхронных запросов открываются отдельные коннекции
С точки зрения сервера это разные окннекции

cityzen · Post by **cityzen** » 27 Apr 2004 23:52

Dmitry67 wrote:В web коннекция переоткрывается при каждом клике.

Not necessarily . AFAIK.

cityzen · Post by **cityzen** » 27 Apr 2004 23:53

Dmitry67 wrote: Ну так для https она и так не может перепрыгнуть

Not necessarily. AFAIK.

Big Cheese · Post by **Big Cheese** » 28 Apr 2004 00:20

Dmitry67 wrote:1. В чем Вы видите не масштабируемость stateful приложений ? В том что на кажлую коннекцию не создать thread ? Сколько занимает thread ? Сколько поместится threads на 4Gb сервере ? Сколько поместится на 64bit сервере ?

Stateful приложение не обязательно означает 1 server thread на каждый connection.

Максимальное количество threads в Win32 процессе можно грубо прикинуть, разделив доступный virtual address space процесса (обычно - 2GB, в военное время может достигать 3GB) на thread stack size (в VC++ по умолчанию 1MB, если мне память не изменяет). Т.е примерно до ~2000 threads наплодить можно, только такая система будет плохо масштабируемой, как мне видится...

JustMax · Post by **JustMax** » 28 Apr 2004 00:28

Dmitry67 wrote:В Winforms я могу открыть коннекцию и если она не рвется то держать ее
В web коннекция переоткрывается при каждом клике.

Дима - то что ты защищаешь - это всего лишь старая добрая технология клиент/сервер - ограниченность которой была доказана тысячу раз и лет так 6-7 назад на эту тему было сломано очень много копий. Начинать заново не вижу смысла.
HINT - найти принципиальные различия между "физической" сессией создаваемой native клиентами с базой данных и "виртуальной" сессией между tiers в multi-tiers приложении (Веб-приложения здесь может и не быть - это всего лишь частный случай одной из tiers), кроме разного уровня абстракции.