Стресс-тестирование веб-приложений на менее надежном оборудовании

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

Проблема заключается в нашей среде, в которой мы выполняем стресс-тестирование, тестирование производительности, тестирование производительности и т.д.

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

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

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

Есть ли достоинство с этой точки зрения? Если да, то почему? Каковы источники этой нелинейности?

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

Изменить: я ценю все мысли до сих пор, но я действительно надеялся, что кто-то сделает больше, чем повторит утверждение одной или другой стороны, и фактически решает вопрос "почему". Если есть такая нелинейность, что порождает ее? Лучше еще было бы здорово, если бы причины были выражены в терминах процессора, памяти, полосы пропускания, задержки, взаимодействия между подсистемами, что у вас... TerryE, вы пришли ближе всего. Вы должны повторно опубликовать свой комментарий в качестве ответа для награды, если никто другой не достигнет уровня

Ответ 1

Предположение инженеров сети заключается в том, что скромная система - это в основном масштабная модель производственной системы. Они также предполагают, что различные характеристики производственной среды, которые влияют на производительность программного обеспечения, отражаются в более скромной системе только на более низких уровнях, но в тех же соотношениях. Например, процессор не так быстр, не так много памяти, хранилище немного медленнее и т.д., И все эти различия находятся в одинаковых соотношениях, так что если бы все было магически умножено на некоторый коэффициент, скажем 1,77, результирующая измененная скромная система будет точно такой же, как производственная система.

Однако, чтобы скромная система была точной масштабной моделью во всех деталях производственной системы, мне трудно поверить.

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

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

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

Некоторые цитаты. Компьютерные системы - это динамические системы от Tod Mytkowicz, Amer Diwan и Elizabeth Bradley.

Байесовское обнаружение и диагностика неисправностей в динамических системах Ури Лернер, Рональд Парр, Дафна Коллер и Гаутам Бисвас.

Ответ 2

Ваш разработчик программного обеспечения прав, и я еще раз остановлюсь.

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

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

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

Ответ 3

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

Мы разместили более 2.5 миллионов веб-сайтов, хотя это может быть не так, но позвольте мне сказать вам это, что в нашем случае мы столкнулись с ужасными ситуациями линейных узких мест. Смысл, мы сначала столкнулись с проблемами памяти, когда наш трафик увеличивался. Мы решили это, добавив больше памяти. До тех пор мы даже не заметили, что только 256 потоков httpd были нашим следующим узким местом, потому что ограниченная память скрывала его, как только мы решили проблему с памятью, это быстро сводилось к проблеме, почему наши веб-серверы были медленными снова через несколько недель? Мы выяснили, что 256 HTTP-потоков просто недостаточно, чтобы обслуживать такой трафик. Мы не только увеличили потоки, но и установили балансировщики параллельной нагрузки HA перед нашими WebServers для смягчения проблемы.

К счастью, он решил проблемы с медленной загрузкой страницы. Но через несколько месяцев, когда движение непрерывно росло, мы попали в очередное узкое место системы хранения. Вы знаете, что это проблема с дисками ввода/вывода. Чтобы сделать рассказ коротким, мы поставили параллельные физические системы хранения на основе NFS. Каждая машина NFS теперь обслуживает файлы, имея более 2000 потоков.

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

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

Что я узнал за последние 6 лет, которые стараются DISTRIBUTE, ваша модель AS MUCH AS ВОЗМОЖНА, если вы считаете, что у вас может быть много трафика или хитов/сек. Централизованная модель может удерживать ваш трафик в течение некоторого времени, делая много настроек, но, в конце концов, ваша система распадается.

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

** Извините за мой английский.

Ответ 4

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

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

если у вас есть номера, то вам не нужен точный результат теста. вам просто нужно знать порядок величины. вы также должны проверить, как ваш программный/аппаратный масштаб. сколько экземпляров вам необходимо обрабатывать x users/requests/whatever и сколько для обработки y

Ответ 5

Мы ежедневно загружаем тестовые системы для наших клиентов - и мы видим широкий круг проблем. Определенные классы проблем можно найти в системах с меньшим размером. Другие не могут. Некоторые могут ТОЛЬКО быть найдены в производстве... потому что независимо от того, насколько близко вы зеркалируете две системы, они никогда не могут быть идентичными. Вы можете получить ДЕЙСТВИТЕЛЬНО близко, если вы достаточно усердно работаете.

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

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

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

Ответ 6

Я думаю, что вы частично ответили на свой собственный вопрос - у вас уже есть среда уровня производства, и они уже находят, что она не на том же уровне/не способна, как в производственной среде. Суть в том, что со всеми деньгами в мире вы никогда не сможете воспроизвести точное функционирование веб-сайта производства - тайминги событий, томов, использования процессора, использования памяти, db IO, когда все это работает в гневе поведением может быть недетерминированным до некоторой степени. Я хочу сказать, что вы никогда не сможете сделать это точно так же. А на другой стороне монеты производственная среда по своей природе будет дорогостоящей средой с множеством наборов, чтобы заставить ее выполнять и обрабатывать объем вашей продукции/транзакций. Это большой расход/накладные расходы для бизнеса, и в эти времена бережливости мы не должны стремиться избежать дополнительных затрат для бизнеса.

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

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