Планирование емкости веб-сервера: больше ядер против большего объема памяти - PullRequest
3 голосов
/ 04 марта 2009

У нас есть проект ASP.NET (около 40 веб-форм, 50 таблиц, довольно стандартные вещи ввода-вывода, которые по возможности сведены к минимуму), которые вскоре должны быть развернуты. В системе будет около 100 одновременно работающих пользователей, но только около 20 одновременно будут работать над ней. Мы будем развертывать его на Windows Server 2008, изначально 32-разрядной.

При рассмотрении спецификации производственного сервера, о чем следует больше беспокоиться, получить больше ядер и меньше памяти (например, 4 ядра и 4 МБ) или больше памяти и меньше ядер (2 ядра и 8 МБ)?

Помогло бы использование 64-разрядной версии Windows Server с использованием памяти?

Ответы [ 2 ]

6 голосов
/ 04 марта 2009

32-битный Windows Server может адресовать только ~ 3 ГБ памяти. Получите 64-битные, 2 ядра и 4 ГБ. Или, если деньги не проблема, получите 8 ядер и 24 ГБ. Дело в том, чтобы никогда не догадываться. Если ты угадал, ты ошибаешься. Контролируйте давление памяти и загрузку процессора и покупайте больше / обновляйте по мере необходимости. Невозможно и глупо пытаться угадать, каким будет узкое место в производительности. Способ only состоит в том, чтобы измерять, измерять, измерять и реагировать в соответствии с этим.

1 голос
/ 11 мая 2009

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

Использование? Только если вы снимаете для> 3,5 ГБ оперативной памяти. А с 20 активными пользователями одновременно вам понадобятся все 4 ядра и значительный кеш, потому что последнее, что вам нужно, - это данные одного активного пользователя, выгружаемые из кеша для загрузки данных других активных пользователей, только чтобы попасть на диск чтобы получить данные первых пользователей, когда они предпримут следующее действие, отправив данные других активных пользователей из кэша ... (читай: избиение).

...