Разрабатывается архитектура системы .NET 2.0 со средним слоем на Web Services. По требованиям система должна выдерживать до 5000 одновременных пользователей. Стоит вопрос в масштабировании среднего слоя. MS на сколько я понял для этого предлагает NLB как средство масштабирования и Application Center 2000 как средство управления. Что смущает: NLB не учитывает загрузку процессора и памяти при распределении нагрузки. Application Center 2000 на сколько я понял дальше не развивается и практически не поддерживается. Продукту судя по названию уже 7 лет . Подскажите плз кто знает альтернативные продукты масштабирования решений на базе .NET 2.0 WebServices. Хотелось бы нормальный балансировщик и инфраструктуру для управления развёртыванием, логами и т.д.

Здравствуйте, basis, Вы писали:

Application Server — умер и уже давно. Посмотри вот этот документ, там по моему ответы на твои вопросы по Microsoft. здесь

Здравствуйте, basis, Вы писали:

B>Разрабатывается архитектура системы .NET 2.0 со средним слоем на Web Services. По требованиям система должна выдерживать до 5000 одновременных пользователей. Стоит вопрос в масштабировании среднего слоя.

Нормально написать на с++/cli, что б держал 20000 пользователей — проблема масштабирования отмирает сама сабой

Здравствуйте, remark, Вы писали:

R>Нормально написать на с++/cli, что б держал 20000 пользователей — проблема масштабирования отмирает сама сабой

нормально написать в машинных кода, чтоб держал 200000 пользователей

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, remark, Вы писали:

R>>Нормально написать на с++/cli, что б держал 20000 пользователей — проблема масштабирования отмирает сама сабой

А>нормально написать в машинных кода, чтоб держал 200000 пользователей

Не получится. В машинных кодах не получится более эффективно использовать память. Да и вообще на 200000 памяти должно быть не меряно

R>Нормально написать на с++/cli, что б держал 20000 пользователей — проблема масштабирования отмирает сама сабой

Там дело не в c++/cli, а скорее в SQL

Мне так совершенно очевидно, что узким местом там будет база данных, а не апп-сервера.

Maxim S. Shatskih wrote:
> Мне так совершенно очевидно, что узким местом там будет база данных, а
> не апп-сервера.
Это смотря как писать Например, умным кэшированием можно ускорить все
в разы и сделать CPU-bound.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Мне так совершенно очевидно, что узким местом там будет база данных, а не апп-сервера.


БД — там будет кластер на Oracle 10g. Если этот кластер окажется узким местом, будем решать эту задачу отдельно. Масштабирование апп все равно нужно.

Здравствуйте, Cyberax, Вы писали:

C>Это смотря как писать Например, умным кэшированием можно ускорить все
C>в разы и сделать CPU-bound.

А как кешировать в NLB приложении? В сессии еще понятно. А данные уровня приложения можно закешировать?

Здравствуйте, basis, Вы писали:

B>Здравствуйте, Cyberax, Вы писали:

C>>Это смотря как писать Например, умным кэшированием можно ускорить все
C>>в разы и сделать CPU-bound.

B>А как кешировать в NLB приложении? В сессии еще понятно. А данные уровня приложения можно закешировать?
Существует до фига различных кластеризованных кэшей, как платных, так и бесплатных. Есть в том числе и от Oracle. Прогуглись по кластеризованным кэшам.

basis wrote:
> C>Это смотря как писать Например, умным кэшированием можно ускорить все
> C>в разы и сделать CPU-bound.
> А как кешировать в NLB приложении? В сессии еще понятно. А данные уровня
> приложения можно закешировать?
Например вот так: http://www.tangosol.com/coherence-overview.jsp — как
раз недавно их Oracle приобрел

Всем спасибо за ответы.
Есть еще вопросец. Где можно почитать сколько транзакций в секунду TPS держит NLB кластер на каком железе? Что то типа таблички: на таком железе такой кластер из стольких-то машин — столько-то, на другом железе столько-то машин — столько.

И еще. Где почитать какие требования на каналы связи накладывает система со средним слоем на web сервисах?

Вот, нашел, если кому интересно.