Адресация масштабируемости, производительности в a.net веб-приложение


Я работаю над порталом .net, на котором будет много одновременных пользователей. поэтому масштабируемость, производительность должны быть рассмотрены в дизайне и архитектуре. Мы планируем использовать балансировку нагрузки в приложении.

Имея это в виду, какой был бы лучший способ связи между веб-сервером IIS (хостинг aspx, aspx.cs-файлы) и сервер приложений (хостинг .net-сборок, таких как business logic и data access layer)? Он должен быть .удаленное взаимодействие. NET и веб-сервисов SOAP?или есть какие-то другой подход?

Спасибо.

6 4

6 ответов:

есть ли другой подход? Да-не распределяйте свои объекты. Самый масштабируемый подход заключается в том, чтобы не распределять ваши объекты далеко друг от друга. Спросите себя, почему вы хотите развернуть одну разновидность кода на "сервере приложений", а другую-на"веб-сервере"? Связь, которая происходит между этими двумя слоями, если они распределены, будет намного, намного, намного (и т. д.) дороже, чем локальный вызов.

С сегодняшним 64-битным серверы, со всей этой памятью, и горячие процессоры, и с ASP.NET-превосходное управление памятью, почему бы не поместить вашу бизнес-логику и DAL на ту же физическую машину, что и файлы ASPX? А почему бы и нет?

Если требуется масштабирование, добавьте дополнительные серверы. Простой.

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

Нет хорошей технической причины, по которой веб-страница не должна работать на одном и том же процессоре, совместно использующем один и тот же Виртуальная машина CLR и куча памяти, как уровень доступа к базе данных.

Независимо от того, что вы делаете с распределением, было бы неразумно создавать систему с менее формальными интерфейсами, определяющими связи между слоями. Если вы сохраняете формальные интерфейсы, то для вас не должно быть проблемой измерить эффективность и эффективность распределенного подхода по сравнению с совместным подходом.

Вам действительно нужен сервер приложений? О каком именно размере ты говоришь? Например: Stackoverflow.com имеет ~50k uniques в день и не имеет сервера приложений, так что я предполагаю, что вы говорите гораздо больше, чем это? Большинство бутылочных горлышек производительности сводится к проблемам базы данных, поэтому я бы сосредоточился на этом.

Я предлагаю вам взглянуть на паттерны и практики групп руководства по производительности, более конкретно Глава 6-улучшение ASP.NET исполнение руководства. Я согласен с Чизо, что вы должны серьезно подумать о том, чтобы физически не разделять свой слой приложений и слой пользовательского интерфейса, если вы можете. Руководство P&P содержит следующие Примечания:

Избегайте Ненужных Технологических Прыжков

Хотя технологические хмели не так дороги, как машинные хмели, вы следует избегать обработки хмеля, где это возможно. Переходы процессов вызывают дополнительные накладные расходы, поскольку они требуют межпроцессной связи (IPC) и маршалинга. Например, если ваше решение использует корпоративные службы, по возможности используйте библиотечные приложения, если только вам не нужно поместить приложение корпоративных служб на удаленный средний уровень.

Понять последствия для производительности удаленного среднего уровня

По возможности избегайте накладных расходов на межпроцессные и межкомпьютерные операции. связь. Если ваши бизнес-требования не требуют использования удаленного среднего уровня, храните логику доступа к презентации, бизнесу и данным на веб-сервере. Разверните бизнес-сборки и сборки доступа к данным в каталоге Bin приложения. Однако вам может потребоваться удаленный средний уровень по любой из следующих причин:

  • вы хотите разделить бизнес-логику между вашими веб-приложениями с выходом в Интернет и другими внутренними корпоративными приложениями.
  • ваши требования к масштабированию и отказоустойчивости диктуют использование кластера среднего уровня или серверов с балансировкой нагрузки.
  • Ваша корпоративная политика безопасности требует, чтобы вы не могли размещать бизнес-логику на своих веб-серверах.

Если вам все равно придется разделить логику приложения, вы можете использовать WCF в качестве транспортного механизма. Я не уверен, как он складывается против удаленного доступа, Когда дело доходит до производительности. Тем не менее, я, кажется, помню, что это руководство Microsoft подталкивает.

Клеменс Vasters (технический руководитель Майкрософт .Чистый автобус) рассказывает о WCF и Remoting в ответ на форумах MSDN.

Учитесь писать асинхронно.
Изучить среды кластера с непрерывной репликацией, например.

Каждый поток , который заблокирован в ожидании ответов ввода-вывода, является одним доступным для вашей системы.

Выключите "идеализированное ведение журнала", оставьте возможность снова включить его через консоль администратора. Но лесозаготовки-это часто скрытое бутылочное горлышко.

КЭШ - КЭШ-КЭШ!

Если было дорого получить данные в первый раз, не платите за это во второй!

Избегать ASP.net s Состояние сеанса-это может серьезно раздуться и привести к большому замедлению отклика страницы.

Измените заголовки http, чтобы указать короткое кэширование браузера (5sec-20sec) (зависит от характера содержимого)

Используйте GZIP, пока вы на нем!

И ИСПОЛЬЗОВАТЬ МНОГО ОПЕРАТИВНОЙ ПАМЯТИ

Вот мои советы

1)переместите все ваши статические файлы-изображения, css, js в балансировщик нагрузки, такой как nginx. Это значительно снизит нагрузку на сервер IIS, и у него будет достаточно свободных ресурсов для обслуживания основного запроса.

2) Подумайте о кэшировании и вообще об отказе от доступа к базе данных. 3) старайтесь реализовать принципы покоя как можно дальше. 4) сведите состояние сеанса к минимуму - по возможности избегайте его вообще.

В этих статьях есть некоторые хорошие моменты производительности и масштабируемости от Omar Al Zabir.
10 ASP.NET секреты производительности и масштабируемости
и еще
99.99% доступно ASP.NET и SQL Server SaaS Production Architecture
(также ознакомьтесь с его книгой создание портала Web 2.0 с ASP.NET 3.5)