Оценка нагрузки для приложения ASP.Net / SQL Server

Нет простой математической формулы для определения нагрузки, с которой вы столкнетесь. Ваша нагрузка может резко измениться в зависимости от:

• Запросы - если вы используете курсоры, например, вам понадобится больше энергии, чем если вы используете операции на основе множеств. Все, что нужно, это один плохо спроектированный запрос, чтобы поставить сервер на колени.
• Индексы - хороший администратор базы данных может сделать разницу между приложением, работающим быстро или медленно.
• Объем исторических данных - поскольку ваше приложение не используется в течение более длительных периодов времени, можно хранить больше данных, что влияет на то, как быстро SQL Server может возвращать результаты вашего запроса. Если ваше приложение быстро удаляет историю, это даже лучше.
• Аппаратные настройки - например, правильно настроенная SAN может выдерживать гораздо большую нагрузку, чем неправильно настроенная SAN.

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

Существует огромное количество переменных, которые необходимо учитывать, поэтому простого способа сделать это не существует. Несколько вещей, которые вы захотите рассмотреть (в дополнение к превосходным заметкам Брента Озара):

• Насколько велик ваш набор данных? Каковы ваши ожидаемые темпы роста и модель?
• Как эти услуги будут разделены? Отдельные веб и sql серверы? Может ли ваше приложение масштабироваться до фермы каждого из них?
• Большая часть работы выполняется вашим приложением в сети или с помощью SQL-запросов?

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

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

Этот подход не позволит вам запустить один большой шторм, но в дальнейшем он избежит многих головных болей.

Там нет серебряной пули; и в зависимости от характера вашего приложения вы можете увидеть больше нагрузки с меньшим количеством пользователей. Например, большое количество Ajax на сайте может значительно увеличить нагрузку на серверы Web и DB.

Я слышал, что ~75 одновременных пользователей на 1 ГБ ОЗУ и одноядерный ЦП на веб-сервере - безопасная оценка. Таким образом, ваш типичный 8GB / Quad Core Server должен обслуживать множество пользователей. Если вы дойдете до этой точки, пропускная способность может также начать играть роль в вашей нагрузке.

Я не особо разбираюсь в SQL Server, но я думаю, что применяются аналогичные цифры.

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

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

Какая у вас платформа web/db?

Если вы используете IIS и SQL Server, Microsoft предлагает несколько инструментов для стресс-тестирования / тестирования производительности ваших сайтов. Инструменты IIS

Эта статья кажется хорошим началом для тестирования SQL Server.