Высокопроизводительная настройка ASP.NET

Question

Я хотел бы спросить вас, какая установка лучше всего подходит для следующего приложения:

ASP.NET 3.5 Веб-сайт - используется в качестве уровня представления, много AJAX и JS. Не сильно ударит по серверу.

ASP.NET WCF - служба, предоставляющая все данные приложению. Он отвечает за валидацию, моделирование / подготовку данных и связь с сервером БД.

База данных - SQL Server 2005 Std, некоторая логика кодируется на стороне сервера как хранимые процедуры. Некоторая логика может занимать немного времени. На мой взгляд, это самая ресурсоемкая часть приложения.

Веб-сайт может иметь до 1000 пользователей в минуту. У нас может быть до 4 серверов в следующей конфигурации: Intel Bi Xeon Quad 8x 2,00+ ГГц, 16 ГБ ОЗУ, SSD или RAID.

Как лучше всего разместить части приложения на физических серверах? Они справятся с такой нагрузкой?

Answer 1

Менее масштабируемое место в любом приложении - сервер базы данных, вы можете добавить больше веб-серверов и серверов приложений, но вы не можете с одинаковой легкостью реплицировать БД, поэтому в долгосрочной перспективе вы выиграете, если БД не будет содержать никакой логики, особенно длительная логика. Во многих приложениях ограничивающим фактором является не процессор, а память для пользовательских сеансов. Если вы сохраняете 1 МБ данных на пользователя, ваши приложения смогут поддерживать 64 000 пользовательских сеансов silmantanius с вашими компьютерами, этого может быть достаточно или нет. Обе проблемы могут быть смягчены с помощью кэширования на уровне приложения, но это может вызвать ряд проблем, поскольку теперь вы столкнулись с устаревшими данными. Для масштабирования сайтов, основанных на сеансах, вам необходимо использовать интеллектуальное решение балансировки нагрузки, которое поддерживает липкие сеансы, для ваших нагрузок, скорее всего, вам потребуется аппаратный балансировщик нагрузки.

Answer 2

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

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

Это большая тема. В попытке дать достаточно исчерпывающий ответ именно на этот вопрос, я закончил тем, что написал книгу об этом: Сверхбыстрый ASP.NET: создание сверхбыстрых и масштабируемых веб-сайтов с использованием ASP.NET и SQL Server .