Решение проблемы масштабируемости и производительности в веб-приложении .net

Question

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

Имея это в виду, каков наилучший способ связи между веб-сервером IIS (размещением файлов aspx, aspx.cs) и сервером приложений (размещением сборок .net, таких как бизнес-логика и уровень доступа к данным)? Это должен быть .net remoting или мыльный веб-сервис? Или есть какой-то другой подход?

Спасибо.

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Клеменс Вастерс (технический руководитель Microsoft .NET Service Bus) рассказывает о WCF и Remoting в этом ответе на форумах MSDN.

Answer 4

Научитесь писать асинхронно.
Изучите время выполнения CCR, например.

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

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

CACHE CACHE CACHE!

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

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

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

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

И ИСПОЛЬЗОВАТЬ МНОГО ОЗУ

Answer 5

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

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

2) Подумайте о кэшировании и об отказе от доступа к базе данных вообще.

3) Попробуйте реализовать принципы REST как можно дальше.

4) Поддерживайте минимальное состояние сеанса - по возможности избегайте его полностью.

Answer 6

В этих статьях есть несколько хороших моментов производительности и масштабируемости от Омар Аль Забир .
10 секретов производительности и масштабируемости ASP.NET
и
99,99% доступно. Архитектура SaaS для ASP.NET и SQL Server.
(также ознакомьтесь с его книгой Создание портала Web 2.0 с ASP.NET 3.5 )