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

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

У меня есть: 1 сервер БД MySQL и 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. Предполагая, что параллелизм недостижим (из-за вышеупомянутых «проблем») и возможна только следующая лучшая вещь, называемая параллелизмом, как мне выбрать аппаратное обеспечение и спецификацию сети для использования моей симуляции. Например, (а) Насколько мощными должны быть мои ПК, генерирующие нагрузку? (b) Сколько виртуальных пользователей создать на каждом из этих ПК? (c) Должен ли каждый ПК в локальной сети подключаться к серверу через коммутатор (во избежание) широковещательного трафика, который возник бы, если бы вместо коммутатора использовался концентратор?

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

/HS


person Harry    schedule 27.01.2011    source источник


Ответы (4)


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

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

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

person Gareth Davidson    schedule 29.01.2011
comment
Газ, я нашел ваши первые 2 абзаца действительно проницательными; Ваше заявление о «прерываниях» полностью меня поразило. Теперь, учитывая то, что вы сказали о прерываниях, кажется, что настоящий параллелизм никогда не может быть достигнут, если и пока у вас нет специализированного оборудования/ОС/программного обеспечения... которое может посвятить себя обработке одной «задачи», данной ему по сети. , при этом сеть также выделена для данного пользователя. Также представляется, что большего параллелизма можно добиться за счет горизонтально масштабируемых аппаратно-программных и аппаратно-программных архитектур, чем за счет масштабирования. Есть ли книга/ресурс, который охватывает выявление узких мест каждого... - person Harry; 29.01.2011
comment
... абстракция/уровень (от конечного пользователя к центральному процессору, выполняющему фактическую работу)... с помощью некоторых интеллектуальных вычислений, которые могут помочь уменьшить масштаб грубого подхода к тестированию и измерению очень большого комбинаторного набора переменных. Спасибо большое! - person Harry; 29.01.2011
comment
Я боюсь, что тип понимания, который вы ищете, будет означать чтение о каждом уровне вашей системы, начиная с протоколов, которые вы используете на самом высоком уровне, и заканчивая пониманием аппаратных архитектур и проприетарного программного обеспечения, работающего на нем. Возможен ли истинный параллелизм, или Вселенная тоже мультиплексирована во времени? Такие философские вопросы не очень полезны для решения поставленной задачи, в практическом мире параллелизм зависит от вашего взгляда на то, что составляет транзакцию... - person Gareth Davidson; 29.01.2011
comment
... Я думаю, книга по теории сетей даст вам лучшую теоретическую базу, но это все еще академические, а не практические знания. Лучше начать с верхнего уровня и специализироваться, когда вам нужно более глубокое представление о том, что происходит, будьте любопытны. В вашем случае вам нужно понять ваши системные счетчики Windows; ЦП, ОЗУ, ошибки страниц, очередь выполнения и т. д. Затем уровень TCP/IP, счетчики JVM, MySQL и UNIX. У систем всегда есть узкие места, найти их — дело науки, а упреждать их — с опытом... - person Gareth Davidson; 29.01.2011
comment
...однако любой приличный инженер-программист скажет вам, что ранняя оптимизация - это зло, вы рискуете потратить 10% своего времени на написание оптимизаций, дающих ускорение на 1%. Единственный разумный способ сделать что-то — это профилировать, собрать понимание, переработать проблемные области и повторять до тех пор, пока затраты не перевесят вознаграждение. Сами нагрузочные тесты — это просто еще одна компьютерная программа, вы должны следовать аналогичной методике. Полное использование вашего комплекта может показаться хорошей целью, но в реальном мире вам просто нужно выполнить осязаемые требования, такие как x одновременных запросов, y в минуту, 90% менее z секунд и т. д. - person Gareth Davidson; 29.01.2011
comment
Спасибо. (Я думаю, вы хотели сказать... повторять до тех пор, пока вознаграждение не перевесит затраты.) - person Harry; 31.01.2011

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

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

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

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

person Seth    schedule 27.01.2011
comment
Сет, я понимаю, что тестирую сервер, а не клиент. Чего я не знаю, так это того, как определить (и использовать) пиковые возможности клиента, сервера и сети, не «подвешивая» какой-либо компонент системы каким-либо образом. Например. есть накладные расходы на переключение контекста с потоками ОС (каждый виртуальный пользователь является потоком ОС) ... поэтому я был / не уверен, смогу ли я иметь 200, 300 виртуальных пользовательских потоков, не тратя слишком много времени на переключение контекста. В: Есть ли книга/ресурс, в которых рассматриваются такие концепции настройки производительности? Спасибо за ваш ответ. - person Harry; 28.01.2011

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

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

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

Такие проблемы, как сетевая задержка, о которой я упоминал (не забывайте о проблемах 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).

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

person BonanzaDriver    schedule 27.01.2011
comment
Cirrus, ценю ваш ответ. Есть ли книга/ресурс, в котором рассматриваются такие концепции настройки производительности? Какие-нибудь инструменты Linux, которые я мог бы использовать, чтобы нагрузить, контролировать и настраивать мою систему в целом? Я, например, не знаю, как использовать каждый компонент системы (аппаратное обеспечение, программное обеспечение, сеть) на пределе своих возможностей. У меня очень широкое (и поэтому смутное) знакомство с отдельными компонентами системы корпоративного класса, но я не знаю системного подхода к их измерению и настройке. - person Harry; 28.01.2011
comment
Гарри, честно говоря, я не знаю, существует ли такое единственное упоминание. Я занимаюсь созданием клиент-серверных систем более 20 лет (хотя последние 11 лет я специализируюсь на интеграции мобильных устройств и мобильных устройств с серверной частью). Большая часть того, что я знаю, прошла через школу стука головой о стену ... У меня есть докторская степень. Улучшения производительности, которые мы задокументировали, заключались просто в попытке использовать самые быстрые шаблоны кодирования (параллельный, асинхронный - все), измерять, настраивать, тестировать, измерять, настраивать, тестировать.... и в какой-то момент быть довольным результатом. . Не очень научно. - person BonanzaDriver; 28.01.2011

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

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

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

Джеймс Пулли

Модератор

-SQAForums WinRunner, LoadRunner

- YahooGroups LoadRunner, Advanced-LoadRunner

-GoogleGroups лр-LoadRunner

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

Ртутные квасцы (1996–2000 годы)

технический директор, Newcoe Performance Engineering

person James Pulley    schedule 02.04.2011