32-ядерная производительность многопоточности для ASP.NET 4.0 и MS SQL 2008 Web Edition

Ответ: технически 100% -ная емкость - это мечта из-за накладных расходов по управлению большим количеством работы, но MS SQL Server 2008 достаточно хорош для масштабирования ядер / процессоров... Вот диаграмма возможностей: http://msdn.microsoft.com/en-us/library/ms143760.aspx

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

Деньги, потраченные на ЦП (и соответствующие затраты на лицензии SQL), вероятно, будут лучше обслуживаться, если они потратят их сначала на максимальное увеличение всей доступной памяти. Затем посмотрите на более быстрые диски (возможно, на SSD?). Очевидно, убедитесь, что все сетевые проблемы решены, если они еще не рассмотрены. Но самое большое, на что нужно обратить внимание - это код / ​​дизайн. Время, потраченное на оптимизацию существующего кода, скорее всего, даст вам максимальную отдачу

Тем не менее, моя главная рекомендация - потратить сравнительно небольшую сумму денег на аудит профессионалом SQL. Позвольте им дать вам краткое изложение того, что будет лучшим решением вашей уникальной проблемы.

Удачи!

Можете ли вы предоставить больше информации о количестве запросов, которые вы скажете за час или день? Какое оборудование у вас есть в настоящее время? Где сейчас горлышко бутылки? Это процессор или ввод / вывод?

ASP.NET может использовать все ядра. MS SQL 2008 может использовать все ядра и любой объем памяти, который вы позволяете.

Проблема не в программном обеспечении сервера, а скорее в коде, который вы пишете (то есть в приложении ASP.NET), в том, как вы спроектировали свою базу данных (логическую и физическую базу данных), а также в написанных вами запросах и т. Д.

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

Вы должны собрать много данных об использовании вашего текущего аппаратного обеспечения и профилировать ваше приложение asp.net и базу данных, чтобы увидеть, что вызывает стресс.

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