Chrome пишет: > > Есть желание программировать интерфейс, практически как экземпляр > десктопного приложения, не сбрасывая граф обьектов пользователя после > каждого запроса. То есть залогинился пользователь — получил на сервере > инстанс приложения интерфейса — и с ним работает. Инстанс не умирает > между запросами. > Программировать в таком стиле легче. Памяти хватит, она дешевая. Что > думаете? Есть ли подводные камни?
Нормальный подход, главное — не забыть вовремя "разлогинить"
пользователя, просто закрывшего браузер (обычно решается с помощью
heartbeat). Кстати, если памяти жалко, между запросами можно
сериализовать объекты на диск (по-моему так делает Spring WebFlow).
Из подводных камней — актуальность объектов, закешированных в сессии
пользователя, их размер. Плюс если пользователи могут модифицировать
один и тот же объект — concurrent modification (эта проблема будет и при
применении традиционного подхода, просто здесь она более явно вылезает).
Ну и про transaction management надо заранее подумать.
--
WBR,
Serge.
Posted via RSDN NNTP Server 2.1 beta
Re: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Периодически возникает необходимость создавать веб интерфейс для пользователей приложений.
C>Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?
А требование именно веб интерфейса чем продиктовано? Заставить веб приложение работать также как десктопное значительно труднее и сложнее в поддержке чем написать такое же, но в нормальном веб стиле. Реально выхода у вас два: вместо "сделать как в винформз" "сделать в winforms" или осознать преимущества stateless и набить руку в программировании веб интерфейсов. Если решите пойти вторым путем — откажитесь от webforms, они намеренно уводят в сторону statefull и постбеков. Попробуйте ASP.Net MVC, там stateless вполне органичен и удобен.
Еще рассмотрите альтернативные варианты типа silverlight'а.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[3]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.
Ну так сделайте стейтфул сервис на сервере который делает полезную работу и напишите к нему морду на винформсах.
C>Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ... C>Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.
vedga
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[15]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>А всетаки надо еще ответить на вопрос: чем такой подход лучше remote desktop?
C>Простотой для клиента — открыл URL в браузере — и работаешь.
URLы они не только для веба.
Никто не мешает тебе сделать приложение, которое будет понимать rdp://<адрес>/
C>Вообще современное состояние технологии remote desktop мне лично внушает большие надежды. C>Работаешь на удаленной машине практически как на своей. C>К сожалению, эта технология предполагает доступ целиком к текущему десктопу, а не к отдельному окну приложения, что требуется для многопользовательского серверного приложения.
Можно настроить автоматический запуск нужного приложения в сессии удаленного доступа.
C>В общем, когда rdp дорастет, эта технология безусловно вытеснит то, что я тут предлагал.
Да и сейчас rdp гораздо эффективнее того что ты предлагал.
Периодически возникает необходимость создавать веб интерфейс для пользователей приложений.
Приложения выполняются на сервере, результаты своей работы сохраняют в базе данных.
Пользователь должен иметь возможность создать задание, редактировать его, запускать, смотреть статус, выполнять другие аднминистративные функции. По окончании задачи доступны всякие отчеты.
Традиционно интерфейс пишется с использованием парадигм, навязанных asp.net.
То есть интерфейс практически не хранит состояние, максимум немного данных в сессии.
При каждом запросе мы смотрим кто пришел, начинаем думать — что ему нужно — тянуть данные из базы, формируем ответ и все забываем.
Это нормальная практика для приложений, у которых много клиентов.
В моем случае одновременно клиентов единицы, максимум десятки. Больше их не станет, поскольку каждая задача требует много ресурсов сервера, и веб интерфейс не основной фактор нагрузки.
Есть желание программировать интерфейс, практически как экземпляр десктопного приложения, не сбрасывая граф обьектов пользователя после каждого запроса. То есть залогинился пользователь — получил на сервере инстанс приложения интерфейса — и с ним работает. Инстанс не умирает между запросами.
Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?
Re: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Периодически возникает необходимость создавать веб интерфейс для пользователей приложений. C>Приложения выполняются на сервере, результаты своей работы сохраняют в базе данных. C>Пользователь должен иметь возможность создать задание, редактировать его, запускать, смотреть статус, выполнять другие аднминистративные функции. По окончании задачи доступны всякие отчеты. C>Традиционно интерфейс пишется с использованием парадигм, навязанных asp.net. C>То есть интерфейс практически не хранит состояние, максимум немного данных в сессии. C>При каждом запросе мы смотрим кто пришел, начинаем думать — что ему нужно — тянуть данные из базы, формируем ответ и все забываем. C>Это нормальная практика для приложений, у которых много клиентов. C>В моем случае одновременно клиентов единицы, максимум десятки. Больше их не станет, поскольку каждая задача требует много ресурсов сервера, и веб интерфейс не основной фактор нагрузки. C>Есть желание программировать интерфейс, практически как экземпляр десктопного приложения, не сбрасывая граф обьектов пользователя после каждого запроса. То есть залогинился пользователь — получил на сервере инстанс приложения интерфейса — и с ним работает. Инстанс не умирает между запросами. C>Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?
Выделенное — основной аргумент? Если да, то могу посоветовать изучать веб-программирование.
Вообще говоря приложение грамотно написанное с расчетом на высокую нагрузку при малой нагрузке летает как сверхзвуковой истребитель. А если "памяти хватит, она дешевая", то можно увеличить размер кеша и получить еще больший прирост.
Re[2]: Как проектировать слабонагруженное веб приложение
Здравствуйте, gandjustas, Вы писали:
C>>Программировать в таком стиле легче. Памяти хватит, она дешевая. Что думаете? Есть ли подводные камни?
G>Выделенное — основной аргумент? Если да, то могу посоветовать изучать веб-программирование.
G>Вообще говоря приложение грамотно написанное с расчетом на высокую нагрузку при малой нагрузке летает как сверхзвуковой истребитель. А если "памяти хватит, она дешевая", то можно увеличить размер кеша и получить еще больший прирост.
Зачем получать еще больший прирост производительности, если она не является узким местом?
Хочется выяснить, может в рамках описанных условий возможно применять более простые, дешевые, понятные модели программирования.
Программирование десктопных систем мне кажется очевидно более простым, чем веб программирование нагруженных веб серверов.
Из пушки по воробьям стрелять дорого.
Re[3]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Хочется выяснить, может в рамках описанных условий возможно применять более простые, дешевые, понятные модели программирования.
Asp.Net-ый WebForms — и есть эмулятор десктопа на web. Включаешь ViewState по максимуму и ни о чем не думаешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[4]: Как проектировать слабонагруженное веб приложение
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Chrome, Вы писали:
C>>Хочется выяснить, может в рамках описанных условий возможно применять более простые, дешевые, понятные модели программирования. IB>Asp.Net-ый WebForms — и есть эмулятор десктопа на web. Включаешь ViewState по максимуму и ни о чем не думаешь.
И получаешь мегабайтные страницы, которые даже по 100-мегабитной сетке с заметным лагом передаются.
Кроме того активное использование постбеков (иначе вьюстейт не нужен) разрушает навигацию, это усложняет работу пользователя.
Re[4]: Как проектировать слабонагруженное веб приложение
Здравствуйте, IB, Вы писали:
IB>Asp.Net-ый WebForms — и есть эмулятор десктопа на web. Включаешь ViewState по максимуму и ни о чем не думаешь.
Это он в розовых мечтах майкрософт такой
попытка же применить WebForms как desktop GUI, ни о чем не думая — на практике спотыкается на первом же динамически созданном контроле.
Другие недостатки — необходимость сериализовать и десиарилизовать обьекты приложения — это как минимум муторная работа со всякими иерархиями — а бывают еще и открытые ресурсы...
десктопное прилоение может использовать потоки, в которых исполняется логика задачи и взаимодействовать из этих потоков с интрерфейсом (MessageBox.Show)
В WebForms приходится извращаться, ручками превращая поток в конечный автомат и сериализовать состояние этого автомата в веб форме — типа от пользователя пришел сигнал А, на прошлом шаге мы находились в состоянии Б — значит переходим в состояние С и выполняем соответствующие шаги...
Re[5]: Как проектировать слабонагруженное веб приложение
Здравствуйте, gandjustas, Вы писали:
G>И получаешь мегабайтные страницы, которые даже по 100-мегабитной сетке с заметным лагом передаются.
Ну и что? Автора же масштбируемость не волнует.
G>Кроме того активное использование постбеков (иначе вьюстейт не нужен) разрушает навигацию, это усложняет работу пользователя.
Автор хотел как в десктопе, в десктопе над навигацией не парятся.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[5]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Это он в розовых мечтах майкрософт такой
Это он таким задумывался.
C>попытка же применить WebForms как desktop GUI, ни о чем не думая — на практике спотыкается на первом же динамически созданном контроле.
Создавай статически.
C>десктопное прилоение может использовать потоки, в которых исполняется логика задачи и взаимодействовать из этих потоков с интрерфейсом (MessageBox.Show) C>В WebForms приходится извращаться, ручками превращая поток в конечный автомат и сериализовать состояние этого автомата в веб форме — типа от пользователя пришел сигнал А, на прошлом шаге мы находились в состоянии Б — значит переходим в состояние С и выполняем соответствующие шаги...
Ну, мужик — это веб. Ты думал, в сказку попал? Привыкай. WebForms дает максимум похожести на обычный десктоп.
Правда есть другая альтернатива — Silverlight.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Как проектировать слабонагруженное веб приложение
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>>И получаешь мегабайтные страницы, которые даже по 100-мегабитной сетке с заметным лагом передаются. IB>Ну и что? Автора же масштбируемость не волнует.
Тут не в масштабируемости дело, а в том, что придется бороться с такими "простыми" спосбами, чтобы приложение с приемлимой скоростью работало.
G>>Кроме того активное использование постбеков (иначе вьюстейт не нужен) разрушает навигацию, это усложняет работу пользователя. IB>Автор хотел как в десктопе, в десктопе над навигацией не парятся.
Только кнопку "назад" в браузере не запретишь.
Re[6]: Как проектировать слабонагруженное веб приложение
Здравствуйте, IB, Вы писали:
IB>Ну, мужик — это веб. Ты думал, в сказку попал? Привыкай. WebForms дает максимум похожести на обычный десктоп.
Я догадываюсь, куда я попал, но хочу именно в сказку.
Мне не нравится, что весь граф обьектов живет только время обработки запросов, затем сериализуется, отправляется пользователю, потом снова десиарилизуется и т. д.
Эти приседания можно оправдать для очень большого числа пользователей.
Совершенно не ясно, зачем эти приседания, если пользователей мало и граф обьектов можно хранить в памяти все время сессии?
Быстродействие только увеличится — отсутсвует необходимость сериализации
Размер страниц уменьшится — никакой лишней информации кроме ID и версии формы там не будет нужно
Программу писать станет легче — исчезнет специфика веба.
Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....
IB>Правда есть другая альтернатива — Silverlight.
да, известно. Мне просто более интересно обсудить предыдущий подход.
Re[2]: Как проектировать слабонагруженное веб приложение
Z>А требование именно веб интерфейса чем продиктовано? Заставить веб приложение работать также как десктопное значительно труднее и сложнее в поддержке чем написать такое же, но в нормальном веб стиле. Реально выхода у вас два: вместо "сделать как в винформз" "сделать в winforms" или осознать преимущества stateless и набить руку в программировании веб интерфейсов. Если решите пойти вторым путем — откажитесь от webforms, они намеренно уводят в сторону statefull и постбеков. Попробуйте ASP.Net MVC, там stateless вполне органичен и удобен.
Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.
Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ...
Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.
Re[7]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Я догадываюсь, куда я попал, но хочу именно в сказку.
Тогда тебе не в IT =)
C>Совершенно не ясно, зачем эти приседания, если пользователей мало и граф обьектов можно хранить в памяти все время сессии?
А какая разница? Тебе все равно придется на каждый запрос десериализовывать, а потом сериализовывать состояние обратно, не важно куда — сессия, вьюстейт, база, кеш... Количество приседаний от этого меняется слабо.
Более того, если использовать WinForms из коробки, то большинство приседаний он от тебя скроет, будет практически полная иллюзия десктопа. А конкретно с сессией есть масса чисто детских граблей, например, только из-за настроек веб-сервера у тебя может не быть гарантии, что следующий запрос от того же пользователя получит ту же сессию — тут как повезет.
Добро пожаловать в реальный мир — надоб просто учиться работать со stateless решениями, они вообщем-то даже проще, чем вин-формз, если разобраться.
C>Программу писать станет легче — исчезнет специфика веба.
Никуда она не исчезнет.
C>Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....
Это все иллюзии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[7]: Как проектировать слабонагруженное веб приложение
Здравствуйте, gandjustas, Вы писали:
G>Тут не в масштабируемости дело, а в том, что придется бороться с такими "простыми" спосбами, чтобы приложение с приемлимой скоростью работало.
Какой вопрос, такой ответ. Автор хотел как в десктопе — вот ровно как в десктопе он и получит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[7]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Программу писать станет легче — исчезнет специфика веба. C>Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....
Это фантастика. Специфика веба никуда не уходит. Можно поптыаться её скрыть, но это cильно нарушает привычний пользователям порядок работы веба.
Всето того чтобы сокрушаться по поподу неудобства разработки для веба лучше научиться этой самой разработке. Никаких проблем в этом нет.
ЗЫ. Statefull UI можно и на javascript сделать.
Re[3]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры.
Здесь логический прыжок — описанные требования никак не ведут к именно веб интерфейсу. C>Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ...
Потому, что HTML — это нихрена не Windows Controls. А HTTP — это не message loop.
Теоретически, можно замутить на аяксе архитектуру, аналогичную WinForms, и некоторые это даже делают. В результате получается плохая пародия на Remote Desktop.
C>Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms.
А чем вас не устраивает Remote Desktop? Для описанной ситуации — самая та технология, что нужно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали: C>Я догадываюсь, куда я попал, но хочу именно в сказку. C>Мне не нравится, что весь граф обьектов живет только время обработки запросов, затем сериализуется, отправляется пользователю, потом снова десиарилизуется и т. д.
C>Эти приседания можно оправдать для очень большого числа пользователей.
Нет. К числу пользователей это не слишком относится. Это относится к тому, как работает протокол HTTP и стандартный веб-браузер. C>Совершенно не ясно, зачем эти приседания, если пользователей мало и граф обьектов можно хранить в памяти все время сессии?
C>Быстродействие только увеличится — отсутсвует необходимость сериализации C>Размер страниц уменьшится — никакой лишней информации кроме ID и версии формы там не будет нужно
Да, есть такая секретная техника в WebForms — хранение viewstate на серверной стороне. C>Программу писать станет легче — исчезнет специфика веба.
Чтобы исчезла специфика веба, нужно убрать саму специфику веба. То есть эмулировать протокол RDP поверх HTTP. Совершенно непонятно, зачем это делать, когда для этих случаев есть RDP. Напоминает историю про мышей и кактус. C>Плюс потоки управляющей логики могут спокойно переживать несколько взаимодействий с пользователем — не надо выворачивать наизнанку алгоритмы....
IB>>Правда есть другая альтернатива — Silverlight. C>да, известно. Мне просто более интересно обсудить предыдущий подход.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Chrome, Вы писали:
C>>Требование веб интерфейса продиктовано тем, что полезную работу приложение выполняет на сервере, у пользователя нет мощьностей и инфраструктуры. S>Здесь логический прыжок — описанные требования никак не ведут к именно веб интерфейсу. C>>Почему сложно "сделать как в винформз" мне и интересно, кажется, что нужно всего лишь сделать рендеринг в HTML вместо Windows Controls ... S>Потому, что HTML — это нихрена не Windows Controls. А HTTP — это не message loop. S>Теоретически, можно замутить на аяксе архитектуру, аналогичную WinForms, и некоторые это даже делают. В результате получается плохая пародия на Remote Desktop.
C>>Ну как ремоут десктоп — работаете в десктоп приложением по сети, вся логика на сервере, на клиент передается только отрендеренный внешний вид, обратно события элементов управления, без всякой дурацкой сериализации всего графа обьектов пользователя при каждом запросе как в webforms. S>А чем вас не устраивает Remote Desktop? Для описанной ситуации — самая та технология, что нужно.
Что то никак не удается направить разговор в нужное русло(((
я имею довольно высокую квалификацию касательно разработки веб приложений.
много знаю про браузеры, http, аякс, asp.net, flex и т. д. и т. п. За много лет излазил это дело вдоль и поперек.
Это я к тому, что большинство ответов — попытка просветить меня о существовании того, что мне известно — не интересно.
Интересно следующее. Мне абстрактно кажется, что существует ниша в разработке веб приложений —
приложения с небольшим числом пользователей — где можно применить немного другие подходы к архитектуре, и получить некоторые преимущества, среди которых — неинвертированная запись алгоритмов управляющей логики, отсутствие сериализации состояния при каздом запросе.
Привел пример приложения, вариации которого часто приходится писать — просто что бы стал понятен контекст, в котором видится полезным использование новой архитектуры. Ежу понятно, что и при помощи множества других архитектур можно реализовать эти требования.
Обсудить хочется саму предлагаемую архитектуру.
Вся логика, включая GUI, работает на стороне сервера.
Когда пользователь логинится — на сервере создается инстанс главной формы для данного пользователя — и хранится все время сессии — то есть пока пользователь не разлогинится. В клиентский браузер при каждом запросе отправляются только HTML модифицированных участков формы. ( То, что серверный код пометит каким нибудь методом InvalidateRegion). Управляющие воздействия пользователя диспетчиризируются соответсвующим контролам формы на сервере — и дальше в обработчики. В общем все как на десктопе. Если мы создали динамический контрол — он никуда не денется при следующем callback- будет существовать постоянно. Создали мы какую нибудь хитрую иерархию обьектов в runtime — не надо заботиться о ее сериализации — она спокойно будет жить все время сессии. Из потока управляющей логики спокойно можно вызвать MessageBox.Show или показать любой диалог, подождать пока пользователь ответит и продолжить выполнение потока.
Мне кажется, у этого подхода есть достаточно преимуществ.
Re[5]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Что то никак не удается направить разговор в нужное русло((( C>я имею довольно высокую квалификацию касательно разработки веб приложений. C>много знаю про браузеры, http, аякс, asp.net, flex и т. д. и т. п. За много лет излазил это дело вдоль и поперек. C>Это я к тому, что большинство ответов — попытка просветить меня о существовании того, что мне известно — не интересно. C>Интересно следующее. Мне абстрактно кажется, что существует ниша в разработке веб приложений — C>приложения с небольшим числом пользователей — где можно применить немного другие подходы к архитектуре, и получить некоторые преимущества, среди которых — неинвертированная запись алгоритмов управляющей логики, отсутствие сериализации состояния при каздом запросе.
Эта фраза противоречит выскзыванию про квалификацю выше.
Тебе уже десятком разных способов пытаются донести простую мысль: пока ты работает с вебом — бразузер, веб-сервер, http тебе придется писать приложение так чтобы оно учитывало специфику веба. Пытаться скрыть специфику веба обходится в итоге большими проблемами, чем преимуществами.
C>Вся логика, включая GUI, работает на стороне сервера. C>Когда пользователь логинится — на сервере создается инстанс главной формы для данного пользователя — и хранится все время сессии — то есть пока пользователь не разлогинится. В клиентский браузер при каждом запросе отправляются только HTML модифицированных участков формы. ( То, что серверный код пометит каким нибудь методом InvalidateRegion). Управляющие воздействия пользователя диспетчиризируются соответсвующим контролам формы на сервере — и дальше в обработчики. В общем все как на десктопе. Если мы создали динамический контрол — он никуда не денется при следующем callback- будет существовать постоянно. Создали мы какую нибудь хитрую иерархию обьектов в runtime — не надо заботиться о ее сериализации — она спокойно будет жить все время сессии. Из потока управляющей логики спокойно можно вызвать MessageBox.Show или показать любой диалог, подождать пока пользователь ответит и продолжить выполнение потока. C>Мне кажется, у этого подхода есть достаточно преимуществ.
Нету у него никаких преимуществ.
Между двумя последовательными запросами может пройти бесконечно много времени, не будет инстанс чего-то на сервере жить непонятно сколько.
Это следствие disconnected природы веба.
Так что всетаки надо тебе глубже изучать как все работает.
Re[5]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Вся логика, включая GUI, работает на стороне сервера. C>Когда пользователь логинится — на сервере создается инстанс главной формы для данного пользователя — и хранится все время сессии — то есть пока пользователь не разлогинится. В клиентский браузер при каждом запросе отправляются только HTML модифицированных участков формы. ( То, что серверный код пометит каким нибудь методом InvalidateRegion). Управляющие воздействия пользователя диспетчиризируются соответсвующим контролам формы на сервере — и дальше в обработчики. В общем все как на десктопе. Если мы создали динамический контрол — он никуда не денется при следующем callback- будет существовать постоянно. Создали мы какую нибудь хитрую иерархию обьектов в runtime — не надо заботиться о ее сериализации — она спокойно будет жить все время сессии. Из потока управляющей логики спокойно можно вызвать MessageBox.Show или показать любой диалог, подождать пока пользователь ответит и продолжить выполнение потока. C>Мне кажется, у этого подхода есть достаточно преимуществ.
Кстати, описываемый подход 1-в-1 повторяет работу remote desktop.
Чем rdp не подходит?
Re[8]: Как проектировать слабонагруженное веб приложение
Здравствуйте, IB, Вы писали:
. IB> А конкретно с сессией есть масса чисто детских граблей, например, только из-за настроек веб-сервера у тебя может не быть гарантии, что следующий запрос от того же пользователя получит ту же сессию — тут как повезет.
если один веб сервер (не ферма) это как возможно ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1231>>
Re[9]: Как проектировать слабонагруженное веб приложение
Здравствуйте, gandjustas, Вы писали:
G>Эта фраза противоречит выскзыванию про квалификацю выше.
Ну и ладно.
G>Тебе уже десятком разных способов пытаются донести простую мысль: пока ты работает с вебом — бразузер, веб-сервер, http тебе придется писать приложение так чтобы оно учитывало специфику веба. Пытаться скрыть специфику веба обходится в итоге большими проблемами, чем преимуществами.
Мысль эта слишком обща и навязывается без всяких аргументов.
Конкретно — какие проблемы в обсуждаемом контексте?
Что бы выявить такие проблемы и было начато обсуждение.
C>>Мне кажется, у этого подхода есть достаточно преимуществ. G>Нету у него никаких преимуществ.
Преимущества были описаны буквально абзацем выше. Обьясните почему "их нет".
G>Между двумя последовательными запросами может пройти бесконечно много времени, не будет инстанс чего-то на сервере жить непонятно сколько. G>Это следствие disconnected природы веба.
Времени может пройти много, да. Но не бесконечно. Предположим месяц — потом logoff.
почему не будет инстанс столько жить?
G>Так что всетаки надо тебе глубже изучать как все работает.
Это верно. Но банально.
Re[6]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
G>>Тебе уже десятком разных способов пытаются донести простую мысль: пока ты работает с вебом — бразузер, веб-сервер, http тебе придется писать приложение так чтобы оно учитывало специфику веба. Пытаться скрыть специфику веба обходится в итоге большими проблемами, чем преимуществами.
C>Мысль эта слишком обща и навязывается без всяких аргументов. C>Конкретно — какие проблемы в обсуждаемом контексте? C>Что бы выявить такие проблемы и было начато обсуждение.
У тебя же опыт web, flex, ajax и все такое... Сам не догадаешься?
G>>Между двумя последовательными запросами может пройти бесконечно много времени, не будет инстанс чего-то на сервере жить непонятно сколько. G>>Это следствие disconnected природы веба.
C>Времени может пройти много, да. Но не бесконечно. Предположим месяц — потом logoff. C>почему не будет инстанс столько жить?
Потому что не будет. IIS держит appPool 20 минут, потом грохает. За сутки может произойти больше одной перпезагрузки.
Но это не главная проблема. Главная проблема как отлавливать момент закрытия формы. если пользователь будет просто жать кнопку назад? или закрывать браузер? Ты представляешь сколько памяти может схавать удержание инстансов открытыми тем более на месяц?
Кроме того, как обрабатывать орктыие одной формы в нескольких окнах? А если пользователь по каким либо причинам не будет передавать sessionID такая схема как заработает?
Также ты предлагаешь все изменения html производить на сервере. Представляешь насколько медленно будет работать динамичный UI, который банально переключает вкладки или сворачивает\разворачивает блоки, если потребуется запрос на сервер для каждого действия?
Re[10]: Как проектировать слабонагруженное веб приложение
C>>Конкретно — какие проблемы в обсуждаемом контексте? G>У тебя же опыт web, flex, ajax и все такое... Сам не догадаешься?
Демагогия скучна. По сути есть что нибудь?
G>Но это не главная проблема. Главная проблема как отлавливать момент закрытия формы. если пользователь будет просто жать кнопку назад? или закрывать браузер? Ты представляешь сколько памяти может схавать удержание инстансов открытыми тем более на месяц?
Ну, это тривиально. Верхняя оценка равна (число пользователей системы * память под сессию пользователя) скажем (50 пользователей) * (100000 обьектов в сессии) * (100 байт на обьект в среднем) дает ~ 0.5 GB
Вообще, факт наличия открытой формы определяется тривиально — периодическим пингом с клиента.
G>Кроме того, как обрабатывать орктыие одной формы в нескольких окнах? А если пользователь по каким либо причинам не будет передавать sessionID такая схема как заработает?
Для работы нужен только javascript механизм для организации callback типа Xml http request
и все отлично заработает. Ну, если сетевой провод вынуть или javascript отключить, думаю, работать перестанет )))
G>Также ты предлагаешь все изменения html производить на сервере. Представляешь насколько медленно будет работать динамичный UI, который банально переключает вкладки или сворачивает\разворачивает блоки, если потребуется запрос на сервер для каждого действия?
Здравствуйте, Chrome, Вы писали:
G>>Но это не главная проблема. Главная проблема как отлавливать момент закрытия формы. если пользователь будет просто жать кнопку назад? или закрывать браузер? Ты представляешь сколько памяти может схавать удержание инстансов открытыми тем более на месяц? C>Ну, это тривиально. Верхняя оценка равна (число пользователей системы * память под сессию пользователя) скажем (50 пользователей) * (100000 обьектов в сессии) * (100 байт на обьект в среднем) дает ~ 0.5 GB
C>Вообще, факт наличия открытой формы определяется тривиально — периодическим пингом с клиента.
При частых запросах на сервер приложение перестанет быть слабонагруженным. Ты об этом не подумал?
G>>Кроме того, как обрабатывать орктыие одной формы в нескольких окнах? А если пользователь по каким либо причинам не будет передавать sessionID такая схема как заработает? C>Для работы нужен только javascript механизм для организации callback типа Xml http request C>и все отлично заработает. Ну, если сетевой провод вынуть или javascript отключить, думаю, работать перестанет )))
Ну так что по поводу нескольких окон с одной страницей?
G>>Также ты предлагаешь все изменения html производить на сервере. Представляешь насколько медленно будет работать динамичный UI, который банально переключает вкладки или сворачивает\разворачивает блоки, если потребуется запрос на сервер для каждого действия?
C>здесь можно это руками потрогать. Выглядит приемлемо. C>http://component-showcase.icefaces.org/component-showcase/showcase.iface?rvn=1
Пока один визуальные контролы конечно приемлимо, но и не сильно серверная обработка нужна.
Когда будет обработка данных, вот тогда пойдет попа.
Re[10]: Как проектировать слабонагруженное веб приложение
От:
Аноним
Дата:
09.07.09 19:04
Оценка:
Здравствуйте, gandjustas, Вы писали:
C>>Ну, это тривиально. Верхняя оценка равна (число пользователей системы * память под сессию пользователя) скажем (50 пользователей) * (100000 обьектов в сессии) * (100 байт на обьект в среднем) дает ~ 0.5 GB G>
У вас хорошая травка? У меня такой нет ))
Или причина веселья в чем то другом? расшифруйте плиз )
C>>Вообще, факт наличия открытой формы определяется тривиально — периодическим пингом с клиента. G>При частых запросах на сервер приложение перестанет быть слабонагруженным. Ты об этом не подумал?
Подумал. Имелось в виду общее число клиентов в пределах 100 на сервер. Не совсем точно выразился во вступительном сообщении . Но даже в случае 50 одновременных сессий — пинг чере 5 минут — получим 10 пингов в минуту — очень малые издержки.
G>>>Кроме того, как обрабатывать орктыие одной формы в нескольких окнах? А если пользователь по каким либо причинам не будет передавать sessionID такая схема как заработает? C>>Для работы нужен только javascript механизм для организации callback типа Xml http request C>>и все отлично заработает. Ну, если сетевой провод вынуть или javascript отключить, думаю, работать перестанет ))) G>Ну так что по поводу нескольких окон с одной страницей?
В чем тут проблема? В зависимости от логики приложения — либо во всех окнах отрендерится одна серверная форма, либо будет создано по одной серверной форме на каждое открытое окно.
G>>>Также ты предлагаешь все изменения html производить на сервере. Представляешь насколько медленно будет работать динамичный UI, который банально переключает вкладки или сворачивает\разворачивает блоки, если потребуется запрос на сервер для каждого действия?
C>>здесь можно это руками потрогать. Выглядит приемлемо. C>>http://component-showcase.icefaces.org/component-showcase/showcase.iface?rvn=1
G>Пока один визуальные контролы конечно приемлимо, но и не сильно серверная обработка нужна. G>Когда будет обработка данных, вот тогда пойдет попа.
Я так понимаю, если нужна серверная обработка данных, попа пойдет независимо от архитектуры?
Или даже так — поскольку в случае предлагаемой архитектуры дерево контролов уже готово и ждет в памяти, нам не нужны ресурсы для его создания, не нужно пересылать viewstate на сервер, и обратно на клиент пойдет только измененный HTML, могу предположить, что предлагаемый подход только выиграет по времени
Re[11]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, gandjustas, Вы писали:
C>>>Ну, это тривиально. Верхняя оценка равна (число пользователей системы * память под сессию пользователя) скажем (50 пользователей) * (100000 обьектов в сессии) * (100 байт на обьект в среднем) дает ~ 0.5 GB G>> А>У вас хорошая травка? У меня такой нет )) А>Или причина веселья в чем то другом? расшифруйте плиз )
Полгига памяти на 50 пользователей это действительно смешно.
G>>>>Кроме того, как обрабатывать орктыие одной формы в нескольких окнах? А если пользователь по каким либо причинам не будет передавать sessionID такая схема как заработает? C>>>Для работы нужен только javascript механизм для организации callback типа Xml http request C>>>и все отлично заработает. Ну, если сетевой провод вынуть или javascript отключить, думаю, работать перестанет ))) G>>Ну так что по поводу нескольких окон с одной страницей? А>В чем тут проблема? В зависимости от логики приложения — либо во всех окнах отрендерится одна серверная форма, либо будет создано по одной серверной форме на каждое открытое окно.
Ну пример в студию. Ты видимо плохо понимаешь о чем говоришь.
А>Я так понимаю, если нужна серверная обработка данных, попа пойдет независимо от архитектуры?
Нет.
А>Или даже так — поскольку в случае предлагаемой архитектуры дерево контролов уже готово и ждет в памяти, нам не нужны ресурсы для его создания, не нужно пересылать viewstate на сервер, и обратно на клиент пойдет только измененный HTML, могу предположить, что предлагаемый подход только выиграет по времени
Создание дерева контролов почти ничего не стоит. А держать в памяти состояние множества контролов с данными выйдет накладно.
Получается отличный способ из ненагруженного приложения сделать приложение, требющее дофтга ресурсов.
Re[5]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Что то никак не удается направить разговор в нужное русло(((
Потому что русло — не очень нужное. C>я имею довольно высокую квалификацию касательно разработки веб приложений.
Это неочевидно заранее.
C>много знаю про браузеры, http, аякс, asp.net, flex и т. д. и т. п. За много лет излазил это дело вдоль и поперек. C>Это я к тому, что большинство ответов — попытка просветить меня о существовании того, что мне известно — не интересно. C>Интересно следующее. Мне абстрактно кажется, что существует ниша в разработке веб приложений — C>приложения с небольшим числом пользователей — где можно применить немного другие подходы к архитектуре, и получить некоторые преимущества, среди которых — неинвертированная запись алгоритмов управляющей логики, отсутствие сериализации состояния при каздом запросе.
C>Привел пример приложения, вариации которого часто приходится писать — просто что бы стал понятен контекст, в котором видится полезным использование новой архитектуры. Ежу понятно, что и при помощи множества других архитектур можно реализовать эти требования. C>Обсудить хочется саму предлагаемую архитектуру.
C>Вся логика, включая GUI, работает на стороне сервера. C>Когда пользователь логинится — на сервере создается инстанс главной формы для данного пользователя — и хранится все время сессии — то есть пока пользователь не разлогинится. В клиентский браузер при каждом запросе отправляются только HTML модифицированных участков формы. ( То, что серверный код пометит каким нибудь методом InvalidateRegion). Управляющие воздействия пользователя диспетчиризируются соответсвующим контролам формы на сервере — и дальше в обработчики. В общем все как на десктопе. Если мы создали динамический контрол — он никуда не денется при следующем callback- будет существовать постоянно. Создали мы какую нибудь хитрую иерархию обьектов в runtime — не надо заботиться о ее сериализации — она спокойно будет жить все время сессии. Из потока управляющей логики спокойно можно вызвать MessageBox.Show или показать любой диалог, подождать пока пользователь ответит и продолжить выполнение потока. C>Мне кажется, у этого подхода есть достаточно преимуществ.
По сравнению с чем? По сравнению с "классическими" веб-приложениями — может быть. По сравнению с десктопными — вряд ли. HTML как канва для рисования бесконечно более убог, чем даже GDI.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Как проектировать слабонагруженное веб приложение
Здравствуйте, gandjustas, Вы писали:
G>Получается отличный способ из ненагруженного приложения сделать приложение, требющее дофтга ресурсов.
Каждый выбирает для себя...
Видимо, тема себя исчерпала, ввиду обнаружения факта существования готовой библиотеки, в которой реализована обсуждаемая архитектура. Из нее видно, что данный подход можно качественно реализовать и, вероятно, у него существует определенная ниша, где он приемлем(судя по аудитории их сайта — половина от аудитории rsdn). Применять или нет — зависит от проекта, там все надо взвешивать.
Re[13]: Как проектировать слабонагруженное веб приложение
Здравствуйте, Chrome, Вы писали:
C>Видимо, тема себя исчерпала, ввиду обнаружения факта существования готовой библиотеки, в которой реализована обсуждаемая архитектура. Из нее видно, что данный подход можно качественно реализовать и, вероятно, у него существует определенная ниша, где он приемлем(судя по аудитории их сайта — половина от аудитории rsdn). Применять или нет — зависит от проекта, там все надо взвешивать.
А всетаки надо еще ответить на вопрос: чем такой подход лучше remote desktop?
Re[14]: Как проектировать слабонагруженное веб приложение
Здравствуйте, gandjustas, Вы писали:
G>А всетаки надо еще ответить на вопрос: чем такой подход лучше remote desktop?
Простотой для клиента — открыл URL в браузере — и работаешь.
Вообще современное состояние технологии remote desktop мне лично внушает большие надежды.
Работаешь на удаленной машине практически как на своей.
К сожалению, эта технология предполагает доступ целиком к текущему десктопу, а не к отдельному окну приложения, что требуется для многопользовательского серверного приложения.
В общем, когда rdp дорастет, эта технология безусловно вытеснит то, что я тут предлагал.
vedga 
Мы уже победили, просто это еще не так заметно...
