Как я могу спланировать мощность своего веб-приложения и выбрать архитектуру развертывания?

У меня есть веб-приложение ASP.net, развернутое на небольшом экземпляре AWS (двухъядерный AMD, 2,60 ГГц, 1,7 ГБ ОЗУ). Я хотел бы выполнить нагрузочное тестирование на этом сервере для 300 одновременных пользователей, а в будущем я хочу разработать предварительную архитектуру планирования емкости и развертывания для 250 000 зарегистрированных пользователей для моего приложения.

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

Вариант использования и сценарий моего приложения будут следующими:

Сценарий — 250 000 зарегистрированных пользователей в базе данных

Параллелизм – 5–7 %, примерно 17 500

У каждого пользователя есть книжная полка, и предполагается, что каждый пользователь подписан на 10 книг. Каждая книга имеет размер около 25 МБ и 400 страниц.

Случаи использования

  1. Логин пользователя

    • Database authentication & authorization
  2. Посмотреть книжную полку с изображениями книг

    • Книжная полка (.swf) — 400 КБ (загружается для каждого пользователя)

    • Будет загружено 10 изображений книг (по 20 КБ на изображение) (приблизительно)

    • catalog.xml - 30 КБ/пользователь для выделенного для пользователя

    • Примечание. Приблизительно 650 КБ данных загружаются на клиентский компьютер.

  3. Просмотр книги: при нажатии на изображение книги следующие файлы и их размеры будут загружены на клиентский компьютер.

    • One time
    • Reader.swf — 950 КБ (первое скачивание)
    • XML data’s of approximately 100 KB / per book (on click)
      • Book.xml
      • Аннотация.xml
      • Каталог.xml
      • Usersettings.xml 40 КБ * 4 = 160 КБ на пользователя (.swf)
    • Примечание. Приблизительно 1200 КБ данных загружаются на клиентский компьютер.

Может ли кто-нибудь предложить, как я могу поступить с этим?

Заранее большое спасибо, Амар


person Amar    schedule 20.01.2011    source источник
comment
Я знаю, что это старый вопрос, но все еще комментирую его, поскольку нахожу очень хорошая статья по вашему вопросу.   -  person Bacteria    schedule 18.12.2015


Ответы (2)


Достичь первой цели (протестировать 300 пользователей) довольно просто — выберите инструмент для нагрузочного тестирования, создайте сценарии и протестируйте. Затем настройте/оптимизируйте и повторите.

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

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

После того, как вы установили этот базовый уровень, вы можете сделать предварительную оценку общего количества серверов, которые вам понадобятся, и вы можете построить свой кластер. Я рекомендую следующее тестирование с 2 веб-серверами/серверами приложений. Это должно почти удвоить вашу емкость. Если это не так, вам нужно определить, почему, прежде чем переходить к более крупным тестам. Вероятными кандидатами являются настройка балансировщика нагрузки или база данных (если один сервер базы данных обслуживает все веб-серверы и серверы приложений). Иногда в игру вступает что-то более фундаментальное для архитектуры приложения.

Когда вы убедитесь, что масштабирование с 1 до 2 серверов работает оптимально, вы можете приступить к масштабированию до полного кластера и протестировать максимальную емкость. Будьте готовы вернуться, если вы не видите ожидаемой масштабируемости — протестируйте с 3, 4, 5 серверами и т. д.

Надеюсь, это поможет! Удачи :>

person CMerrill    schedule 24.01.2011
comment
Привет Merrill, Спасибо за подробное объяснение. Это действительно очень помогло. Не могли бы вы предложить мне важные факторы производительности, которые следует учитывать при выполнении нагрузочного теста, и сделать предварительную оценку на основе этих факторов производительности. Это бы мне очень помогло, еще раз спасибо. - person Amar; 25.01.2011
comment
Конечно. Мы всегда ориентируемся на производительность конечного пользователя. Это означает, что нас в первую очередь интересует время загрузки страницы и ошибки. В некоторых организациях у вас могут быть некоторые другие критерии, такие как использование ЦП и потребление пропускной способности, которые вы также можете искать, когда вы делите пропускную способность и ЦП с другими приложениями. Затем мы запускаем тесты с возрастающей нагрузкой в ​​ступенчатой ​​конфигурации, чтобы определить уровень пользователя, при котором система больше не соответствует целям производительности: webperformance.com/load_testing/blog/2008/07/ - person CMerrill; 25.01.2011
comment
Спасибо Merrill, я провел цикл нагрузочного тестирования с использованием VSTS для 200 и 400 одновременных пользователей в изолированной сети, используя четырехъядерный сервер и машину P4 для создания нагрузки. Я рассмотрел счетчики производительности VSTS по умолчанию и обнаружил, что использование процессорного времени составляет 14,6%, а использование памяти — 900 МБ для 200 пользователей. Для 400 это было 21,6% процессорного времени и всего 1 ГБ использования памяти. Исходя из этого, я предположил, что четырехъядерный процессор может поддерживать до 1500. Верно ли мое предположение? - person Amar; 31.01.2011
comment
Не могли бы вы также предложить мне, как я могу рассчитать пропускную способность? В отчете я обнаружил, что среднее количество байтов, отправленных в секунду, составляет 10 МБ/сек для 400 одновременных пользователей. Я делал этот нагрузочный тест в течение 15 минут. Спасибо. - person Amar; 31.01.2011
comment
Что ж, вы можете сделать предположение о емкости, но есть большая вероятность, что оно будет неверным. Хотя загрузка ЦП может масштабироваться линейно, она может и не изменяться. Или какой-то другой фактор может ограничить пропускную способность, чего не было с 2-400 пользователями. Только протестировав 1500 пользователей, вы можете быть уверены, что система справится с этим. - person CMerrill; 31.01.2011
comment
В то время как сетевой инженер может рассчитать пропускную способность, вы, как тестер, должны ее измерить, т. е. протестировать. Это единственный способ узнать, сколько у вас есть на самом деле. Вы можете рассчитать максимальную потребность в пропускной способности на основе требований к пропускной способности для одного пользователя. - person CMerrill; 31.01.2011

Эта ссылка: http://support.microsoft.com/kb/231282 содержит ссылки на некоторые инструменты для стресс-тестирования вашего сайта.

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

person Bravax    schedule 20.01.2011
comment
Привет, Bravax, я посмотрю ссылки, которыми вы поделились. Я обновил свой вопрос некоторыми сценариями и вариантами использования. Пожалуйста, ознакомьтесь с ним и посмотрите, может ли это помочь ответить на мой вопрос дальше. Большое спасибо - person Amar; 20.01.2011
comment
250 000 != 2,5 миллиона зарегистрированных пользователей - person Vishal Verma; 06.05.2013