Что такое реалистичное измерение для нагрузочного тестирования веб-приложения CMS?

Question

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

Мы надеялись получить на этом форуме обратную связь о том, что реалистичное ожидание системы CMS должно обрабатываться независимо от технологии, которая была построена. Таким образом, если одно и то же приложение должно было быть встроено в .NET вместо Java (текущее), вы должны будете выполнить то же самое.

Метрики, которые мы придумали:

• Количество одновременных запросов / длина очереди: 100 Максимум
• Время на обработку запроса: минимум 2 с
• Количество запросов в час: 150 000
• Минимальное количество просмотров страниц в час: 5000

Минимальные требования HD: - 2 ГБ оперативной памяти - 2 двухъядерных 2,0 ГГц

Общая функциональность:

• Динамическая перекрестная ссылка Новости, события для людей и новости, Технические случаи и т. Д.)
• Расширенные функции поиска
• Конфигурируемый без программирования

Answer 1

То, что вы должны начать делать, это отслеживать, как люди его используют. Если вы ведете блоги, у вас будут запросы во времени и количество активных сессий и т. Д.

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

Answer 2

Не стоит делать конкретные ожидания производительности и масштабируемости без какой-либо информации об оборудовании, технологии, нагрузке, использовании и т. Д. «CMS» очень широк:

• Как выглядит ваша серверная ферма?
• Каковы условия вашего SLA?
• Как выглядит ваш типичный пользователь? Например. много коротких пользователей или меньше пользователей с длинными сеансами и большим количеством запросов?

Другие важные вопросы, на которые нужно ответить:

• Вы хотите измерить «время до первого байта» (я ненавижу это, но это довольно распространенное явление) или включить задержку сети в ваше общее «время на обслуживание»?
• Сколько редакторов работает против системы?
• Работают ли ваши редакторы на основе одних и тех же данных или готовят контент в изолированной среде и запускают пакеты обновлений контента?
• Какой механизм кэширования вы можете поддерживать? Может ли контент устареть на минуты / часы?

В нашей ферме из нескольких 64-разрядных серверов с балансировкой нагрузки с ~ 32 ГБ ОЗУ (IIRC) и 4 ЦП каждый, мы имеем в среднем чуть менее 100 000 запросов в час с пиковой нагрузкой в ​​несколько сотен запросов / с (редко). Общее время загрузки конечного пользователя (включая изображения и ресурсы) должно быть не более 5 секунд. Наша общая база данных контента CMS составляет чуть менее 750 000 страниц. У нас огромное количество кросс-загруженного контента, запросов, сложных настраиваемых редактором виджетов и т. Д.

Answer 3

Проблемы с выступлениями редко бывают простыми. Честно говоря, вы действительно должны воспользоваться услугами опытного интегратора, зная ОБА CMS, которую вы используете, и оптимизацию производительности. Всегда сложно найти узкие места между сетью / самой CMS / ее реализацией.

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

Answer 4

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

каждый сценарий мы повторяем действие 20 раз.

Мы запускаем 1-й сценарий для 100 одновременных пользователей, начиная с 1 пользователя, увеличивающегося на 5 каждые 30 секунд, и мы позволяем этому запускаться и извлекаем статистику.

Мы запускаем 2-й сценарий для 20 одновременных пользователей, начиная с 1 пользователя, увеличиваемого на 2 каждые 30 секунд

Мы запускаем третий сценарий для 500 одновременно работающих пользователей, начиная с 1 и увеличивая на 10 каждые 5 секунд.

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

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

Answer 5

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

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

В любом случае, я рекомендую вам использовать некоторые инструменты нагрузочного тестирования, такие как JMeter, Silk Peformer, Load Runner и т. Д.