Концептуальный вопрос (подобный инструменту) LoadRunner

Question

Я использую LoadRunner для стресс-тестирования приложения J2EE.

У меня есть: 1 сервер MySQL DB и 1 сервер приложений JBoss. Каждый из них представляет собой 16-ядерный (1,8 ГГц) / 8 ГБ ОЗУ.

Пул соединений: сервер БД использует max_connections = 100 в my.cnf. Сервер приложений тоже использует min-pool-size и max-pool-size = 100 в mysql-ds.xml и mysql-ro-ds.xml.

Я моделирую загрузку 100 виртуальных пользователей с «обычного» одноядерного ПК. Это блок оперативной памяти 1,8 ГГц / 1 ГБ.

Приложение развернуто и используется в локальной сети Ethernet со скоростью 100 Мбит / с.

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

Вопрос:

Загрузка ЦП на этом генерирующем нагрузку ПК никогда не достигает 100%, и, я полагаю, также доступна память. Итак, я могу попробовать добавить больше виртуальных пользователей на этом ПК. Но прежде чем я сделаю это, я хотел бы знать 1 или 2 основы параллелизма / параллелизма и аппаратного обеспечения:

1. Имея только одноядерный генератор нагрузки, как этот, могу ли я действительно имитировать параллельную нагрузку в 100 пользователей (при этом каждый пользователь в реальном времени использует работу с выделенного ПК)? Мое возможно неправильное понимание состоит в том, что 100 потоков на одноядерном ПК будут работать одновременно (то есть с чередованием), но не параллельно ... Это означает, что я не могу реально смоделировать реальную загрузку 100 параллельные пользователи (на 100 ПК) с одного одноядерного ПК! Это правильно?

2. Ограничения пропускной способности сети при параллелизме пользователей: даже если предположить, что у меня был 100-ядерный ПК, генерирующий нагрузку (или, альтернативно, скажем, у меня в локальной сети было 100 одноядерных ПК), это не так. Работа в сети Ethernet допускает только параллелизм, а не параллелизм пользователей в сети Ethernet, соединяющей генерирующий нагрузку ПК с сервером. На самом деле, кажется, что эта проблема (из-за отсутствия пользовательского параллелизма) будет сохраняться даже при использовании приложений в реальном мире (с 1 ПК на пользователя), поскольку пользовательские запросы, достигающие сервера приложений на многоядерном компьютере, могут поступать только с чередованием , То есть, единственное время, когда многоядерный сервер мог обрабатывать запросы пользователей параллельно, было бы, если бы у каждого пользователя было свое собственное выделенное соединение физического уровня между ним и сервером !!

3. Предполагая, что параллелизм недостижим (из-за вышеуказанных «проблем»), и возможна только следующая лучшая вещь, называемая параллелизмом, как бы я выбрал аппаратное обеспечение и спецификацию сети для использования моего моделирования. Например, (а) Насколько мощными должны быть мои ПК, генерирующие нагрузку? (б) Сколько виртуальных пользователей создать на каждом из этих ПК? (c) Должен ли каждый ПК в локальной сети быть подключен через коммутатор к серверу (чтобы избежать) широковещательного трафика, который возник бы, если бы вместо коммутатора использовался концентратор?

Заранее спасибо,

/ HS

Answer 1

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

У меня есть механизм связи, который я создал пару лет назад (.NET / C #), в котором используются асинхронные сокеты - нужны были максимально быстрые скорости, поэтому нам пришлось забыть о добавлении любых дополнительных слоев поверх сокета, таких как HTTPили любые другие высшие абстракции.Работая на четырехъядерном компьютере с тактовой частотой 3,0 ГГц и 4 ГБ оперативной памяти, этот сервер легко обрабатывает трафик ~ 2200 одновременных подключений.Там есть переключатель Gb, и все ПК имеют Gb NIC.Даже при одновременной связи всех ПК редкость загрузки процессора> 30% на этом сервере.Я предполагаю, что это из-за всей задержки, которая присуща «общей системе».

У нас есть новое требование для поддержки 50 000 одновременных пользователей, которое я сейчас внедряю.Сервер оснащен двухъядерными процессорами с частотой 2,8 ГГц, 64-разрядной ОС и 12 ГБ оперативной памяти.Наше моделирование показывает, что этого компьютера более чем достаточно для работы с пользователями 50K.

Такие проблемы, как задержка в сети, о которой я упоминал (не забудьте про CAT 3 против CAT 5 и CAT 6), соединения с базой данных, типыхранящихся данных и средних размеров записи, проблем со ссылками, скорости объединительной платы и шины, скорости и размера жесткого диска и т. д., и т. д. и т. п., играют столь же важную роль, что и замедление платформы «в целом».Я полагаю, что в вашей системе может быть 500, 750, 1000 или даже больше пользователей.

Раньше цель состояла в том, чтобы никогда не оставлять поток заблокированным слишком долго ... новая цельчтобы все ядра были заняты.

У меня есть еще одно приложение, которое ежедневно загружает и анализирует содержание ~ 7800 URL.Работа на двухъядерном ядре с тактовой частотой 3,0 ГГц (64-разрядная версия Windows Ultimate 7) с 24 ГБ ОЗУ, на выполнение этого процесса уходило ~ 28 минут.Просто переключая цикл на Parallel.ForEach (), весь процесс теперь занимает <5 минут.Моя загрузка процессора, которую мы видели, всегда составляет менее 20%, а максимальная загрузка сети - только 14% (CAT 5 на сетевой карте Gb через стандартный тупой концентратор Gb и линию T-1). </p>

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

Answer 2

Мало того, что вы используете Ethernet, предполагая, что вы пишете веб-сервисы, вы говорите по HTTP (S), который расположен поверх TCP-сокетов, надежного, упорядоченного протокола со встроенными обходами, присущими надежным протоколам.Сокеты располагаются поверх IP, если ваши IP-пакеты не совпадают с вашими кадрами Ethernet, вы никогда не будете полностью использовать вашу сеть.Даже если бы вы использовали UDP, настроили свои дейтаграммы так, чтобы они соответствовали вашим фреймам Ethernet, имели 100 генераторов нагрузки и 100 карт Ethernet 1 Гбит на вашем сервере, они все равно работали бы с прерываниями, и у вас было бы время для мультиплексирования немного дальшестек.

Каждый уровень здесь можно рассматривать с точки зрения транзакций, но не имеет смысла думать на каждом уровне сразу.Если вы пишете SOAP-приложение, которое работает на уровне 7 модели OSI , то это ваш домен.Что касается вас, то ваши транзакции - это запросы SOAP HTTP (S), они параллельны и для их выполнения требуется различное время.

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

Answer 3

Звучит так, будто ты слишком обдумал это. Ваши серверы быстрые и новые, и они более чем подходят для обслуживания большого количества клиентов. Узким местом (если оно у вас есть) будет либо само ваше приложение, либо ваша 100-метровая сеть.

1/2. Вы тестируете сервер, а не клиент. В этом случае все, что делает клиент, - это отправляет и получает данные - нет никаких накладных расходов на обработку клиента (рендеринг HTML, декодирование изображений, выполнение javascript и все остальное, что может быть). Недавняя одноядерная машина может легко насытить гигабитную связь; труба 100 мбит должна быть тортом.

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

3. Не используйте концентратор. Есть причина, по которой вы можете купить 100-метровый концентратор за 5 долларов на craigslist.

Answer 4

Поскольку вы представляете пользователей, не обращайте внимания на рандеву, если только у вас нет технических требований для поддержки одновременного поведения или если ваши агенты являются процессами, а не пользователями, и эти агенты управляются тактом.Люди являются хаотичными вычислительными единицами с различными окнами прибытия и отъезда, основанными на том, как быстро можно или нельзя читать, печатать, общаться с друзьями и т. Д. Великая книга на тему поведения населения - «Хаос» Джеймса Глейка (sp?)

Вероятность того, что ваши 100 развязанных пользователей будут очень синхронными в своем поведении на мгновенной основе в наблюдаемых условиях, равна нулю.Однако вероятность одновременной активности в определенном временном окне, например, когда 100 пользователей входят в систему в течение 10 минут после 9:00 в рабочее утро, может быть довольно высокой.

В качестве примечания, резюме с рандевуна нем подчеркивается маркер № 1 для человека с плохим пониманием инструмента и плохим процессом тестирования производительности.Это происходит из фолио более 1500 интервью, проведенных за последние 15 лет (я начал свою работу в качестве сотрудника Mercury 1 апреля 1996 года)

Джеймс Пулли

Модератор

-SQAForums WinRunner, LoadRunner

-YahooGroups LoadRunner, Advanced-LoadRunner

-GoogleGroups lr-LoadRunner

-Linkedin LoadRunner (владелец), LoadrunnerByTheHour (владелец)

*1017* Mercury Alum (1996-2000)

CTO, Newcoe Performance Engineering