Dmitry67 wrote:Strannik223 wrote:Проблемы statefull:
1. Ни клиент ни сервер могут быть не в состоянии определить что другой из них закрыл сессию. Например из за недоступности сети.
2. Большое количество клиентов быстро истощат память сервера своими данными. И не надо считать сколько памяти занимает поток, не много. А вот данных клиент может держать на сервере вобщем случае неопределенный объем. Множим количество клиентов на размер состояния, и получаем полную неопределеннось в потребности сервера в памяти.
3. Клиент может долгое время оставатся бездействующим занимая память на сервере своими данными.
4. Оно не масштабируемо. Сложно построить server farm. А утверждение о том что один сервер справится с любой нагрузкой...
Может сейчас и справится, а через год?
1. А как жто делается сейчас ? Примитивный timeout, и все
2. Нет. я как раз потребую цифр
Практика моей работы показывает что перовым истощается CPU на сериализации а не память
3. Система виртуальной памяти автоматически (и на пааратном уровне) решает эту проблему
4. Почему ? Вы можете поставить в ряд несколько серверов. Да, коннекция не может перепрыгнуть с сервера на сервер. Ну так для https она и так не может перепрыгнуть
1. Почему примитивный, а не простой?
Мысль была в том что для таймаута не надо спецобработчик делать, он сам по себе работает. А для постоянного соединения надо что то програмить, тестировать, а в первой итерации обычно на такие "мелочи" забивают...
2. Просто думал что это очевидно.
N*M где N-количество залогиненых клиентов, M - средний объем данных состояния одного клиента.
Если количество клиентов принять за константу, например ограничив их в документации, то с M сложнее, вы никогда заранее не знаете какова эта величина. То есть можно предполагать что то, но всегда есть высокий риск того что релиз не уложится в границы, в результате будешь объяснятся с разьяренным менеджером продукта "ты же обещал и подсчитывал что оно выдержит X клиентов!!! при таком-то железе"
У нас разные практики
У меня сериализация ничтожно малая величина, основная задержка - sql. Упреждающе: хранимки я писать умею! Возможно надо делать custom serialization?
3. Своп спасает от простаивающих клиентов, но если они активны... система будет свопом заниматся. Например клиент делает действие раз в 2 минуты. Достаточно характерно для офисного приложения.
3. Да, так можно и я даже так делал. Конструкция получается не так гибкой как хотелось бы. Нельзя динамически балансировать нагрузку (роутить каждый запрос индивидуально например), и т д.
<added>
Тяжело (но реализуемо) shutdown сервера, клиент должен быть достаточно умным что бы перелогинится.
</added>
Далее, если вдуматся то IP то же является session-based. В качестве идентификатора сессии выступает пара IP/port. ОС по своей таблице открытых соединений роутит пакеты приложению кторое заявило что слушает этот порт на этом IP. Вам это ничего не напоминает?
Например lookup of Session table.
В общем и целом я согласен с тем что тонкий клиент, то есть web browser очень ограничен и следующий виток эволюции идет к ренесансу client-server.
Возможно свежую волну и спасение браузера принесет SVG-1.2 и его вариант от МС- XAML.
Никакой разрухи нет. (с) Проф. Преображенский.