Максимальная сумма / LIMIT сайтов ASP.NET на одном сервере

Question

Мой вопрос прост.Около 2 лет назад мы начали переход на ASP.NET с ASP Classic.Наша проблема в том, что в настоящее время у нас есть около 350 сайтов на сервере, и сервер, похоже, перегружен.Мы пытались различными способами повысить производительность, Оптимизация запросов , Отключение ViewState , Состояние сеанса и т. Д., И все они работали, но по мере добавления новых сайтовв итоге мы используем больше ресурсов сервера, и поэтому улучшения, которые мы сделали в коде, практически стерты.

По сути, мы сейчас находимся на переломном этапе, наши ЦП в настоящее время составляют в среднем около 100%.Наш IS хотел бы, чтобы мы нашли новые способы переформулировать код на сайтах для повышения производительности.

У меня есть теория, что мы просто ограничиваем количество сайтов, которые может обрабатывать один сервер.

Есть идеи?Пожалуйста, отвечайте, только если у вас есть хорошее представление о том, о чем вы говорите.Я слышал, что многие люди рассуждают о станции.Мне нужен кто-то, кто действительно знает о том, что может происходить.

Вот подробности.

• 250 сайтов ASP.NET
• 250 сайтов администраторов (написанных на ASP.NET, в основном это серверные сайты администратора)
• 100 Классические сайты ASP

Работает на виртуализированной Windows Server 2003.

• 3 процессора, 4 ГБ памяти.
• Память остается на уровне 3 - 3,5 ГБ
• Процессоры очень сильно вспыхивают, иногда они остаются около 100% в течение короткого промежутка времени (30 - 180 секунд)

База данных находится на отдельном сервере и является SQL SERVER 2005.

Answer 1

Похоже, вы достигли этой точки. Вы оптимизировали свои приложения, посмотрели на производительность сервера, вы видите, что вы достигаете пиковой нагрузки на память, увеличиваете нагрузку на процессор, и, как видите, администрирование такого количества веб-сайтов не должно быть легким.

Кроме того, характеристики вашей виртуальной машины не фантастические. В частности, это память, потенциально не очень хорошая для количества сайтов, которые у вас есть.

У вас есть много причин для переезда.

Тем не менее, некоторые вещи, на которые стоит обратить внимание:

1) Сколько из этих 250 сайтов фактически используется? Какие из них являются нарушителями пиковой производительности? Те - главные кандидаты для того, чтобы быть перемещенными в их собственную коробку.

2) Сколько вообще не используется? Вы можете уйти на пенсию?

3) Вы работаете на виртуальной машине. Какую платформу виртуальной машины вы используете? Какие другие серверы работают на этом оборудовании?

4) Какая у вас сейчас избыточность? 250 сайтов на одной коробке без бэкапа? Если у вас есть резервный сервер, вы можете использовать его для округления запросов или в качестве веб-фермы, распределяя нагрузку.

Допустим, вы решили переехать. Первое, о чем вы, вероятно, должны подумать - как.

Собираетесь ли вы просто вдвое сократить количество сайтов? 125+ админов на одном боксе, 125+ админов на другом? Или ты собираешься переместить самый используемый?

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

Судя по всему, есть реальное сопротивление, чтобы купить больше оборудования.

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

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

Answer 2

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

Я думаю, что вы можете найти лучший ответ на сервере, но вот мои 2 цента.

Вы можете увеличивать или уменьшать масштаб.

Масштабирование - модернизируйте машину, добавив больше памяти / больше ядер в ЦП. Масштабирование - распределите нагрузку, разделив сайты на 2 или более серверов. 300 на сервере A, 300 на сервере B или 200 на 3 сервера.

Как упоминает @uadrive, это проблема загрузки, а не количества сайтов.

Answer 3

Я думаю, что вы действительно ответили на свой вопрос.Вы оптимизировали сайты, у вас есть сервер базы данных на другом сервере.И у вас есть 600 сайтов (250 + 250 + 100).

Ответ довольно ясен для меня.Купите коробку с большей памятью и процессором.

Answer 4

Нет простого ответа по формуле, например, «вы можете иметь максимум 47,33 сайтов на гигабайт ОЗУ». Вы, несомненно, могли бы поддерживать производительность на многих других сайтах, если бы на каждом сайте был только один пользователь в день. Вероятно, есть серверы, на которых есть только два сайта, но производительность ужасна, потому что для каждого попадания требуется большой запрос к базе данных.

На практике единственный способ подойти к этому эмпирически: когда производительность начинает ухудшаться, у вас есть проблема. Тот факт, что кто-то где-то написал в книге, что сервер с такими-то ресурсами должен поддерживать больше сайтов, не имеет большого значения, если на практике ВАШ сервер не может поддерживать ВАШИ сайты и ВАШИ пользователи.

Реалистичные варианты:

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

(b) Купить сервер побольше.

(c) Разбейте свои сайты на несколько серверов и либо обновите DNS, либо установите клиентский интерфейс для сопоставления запросов с нужным сервером.

Answer 5

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

Answer 6

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

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

Трудно вносить содержательные предложения, не зная гораздо больше о ваших приложениях, но вот несколькоБыстрые советы, которые могут помочь вам начать:

1. Несколько AppPools стоят дорого.Сколько сайтов у вас на AppPool?Объедините несколько сайтов для каждого AppPool, если вы можете
2. Минимизировать циклические обходы клиента: улучшить кэширование на уровне клиента и прокси, выгрузить статические файлы в CDN, использовать спрайты изображений, объединить несколько файлов CSS и JS
3. Включить кэширование вывода на страницах и / или элементах управления стало возможным
4. Включить сжатие для статических файлов (больше использования ЦП при первом доступе, но меньше после этого)
5. Избегать состояния сеанса все вместе, если вы можете(предпочитаю куки для государственного управления).Если вы не можете, то, по крайней мере, настройте EnableSessionState = "ReadOnly" состояние сеанса для страниц, которые не должны его записывать, или "false" для страниц, которые вообще не нужны
6. Многие вещина стороне SQL Server: кэширование, SqlCacheDependency, пакетирование команд, группирование нескольких вставок / обновлений / удалений в одну транзакцию, использование хранимых процедур вместо динамического SQL, использование асинхронного ADO.NET вместо LINQ или EF, убедитесь, что журналы БДна отдельных шпинделях из данных и т. д.
7. Ищите алгоритмические проблемы с вашим кодом;например, хеш-таблицы часто лучше, чем линейный поиск и т. д.
8. Минимизируйте размеры файлов cookie и устанавливайте файлы cookie только на страницах, а не на статическом содержимом.

Кроме того, при использовании виртуальной машиныСкорее всего, это приведет к снижению производительности примерно до 10%. Убедитесь, что оно действительно того стоит за то, что он покупает с точки зрения улучшения управляемости.