Комментарии 13
Я не совсем понял, что это «нисходящие», «восходящие» bottleneck?
>> Точно так же в такой ситуации может проявиться bottleneck, необнаруженный (и принципиально необнаруживаемый!) на тестовой инсталляции.
Это похоже на псевдонаучные спекуляции («Принципиально необнаруживаемый»).
Мне кажется так вообще нельзя рассуждать, если мы смотрим с точки зрения тестировщика у нас есть черный ящик. Система X с параметрами процессор Y, память Z, сеть N, обеспечивает скорость S. Можно ли сделать вывод, что система (2*Y, 2*Z, 2*N) обеспечит 2*N. Наверное можно было если бы мы все внешние параметры системы знали и могли их увеличить одновременно! Как-то размер L1, L2, L3 кэша, скорость обращения к памяти и т.п. Что практически невозможно.
Я лично камней не вижу берем 1 параметр и строим рассчеты. Система X с сетью N обеспечивает S, проверяем N*2 обеспечивает S*2. Не обеспечивает? Отправляем на доработку или проверяем ожидания, конечно же если в сети нет затыка, чего ее увеличивать… И так надо искать параметр или группу, который сможет более-менее линейно увеличивать скорость. Эта задача называется регрессионный анализ. Выделяете группу параметров и вперёд, делать измерения, строить точки :)
Я уже молчу, что для многопоточных систем на многопроцессорных машинах, вообще, будет ожидать крах всех ожиданий en.wikipedia.org/wiki/Amdahl's_law.
>> Точно так же в такой ситуации может проявиться bottleneck, необнаруженный (и принципиально необнаруживаемый!) на тестовой инсталляции.
Это похоже на псевдонаучные спекуляции («Принципиально необнаруживаемый»).
Мне кажется так вообще нельзя рассуждать, если мы смотрим с точки зрения тестировщика у нас есть черный ящик. Система X с параметрами процессор Y, память Z, сеть N, обеспечивает скорость S. Можно ли сделать вывод, что система (2*Y, 2*Z, 2*N) обеспечит 2*N. Наверное можно было если бы мы все внешние параметры системы знали и могли их увеличить одновременно! Как-то размер L1, L2, L3 кэша, скорость обращения к памяти и т.п. Что практически невозможно.
Я лично камней не вижу берем 1 параметр и строим рассчеты. Система X с сетью N обеспечивает S, проверяем N*2 обеспечивает S*2. Не обеспечивает? Отправляем на доработку или проверяем ожидания, конечно же если в сети нет затыка, чего ее увеличивать… И так надо искать параметр или группу, который сможет более-менее линейно увеличивать скорость. Эта задача называется регрессионный анализ. Выделяете группу параметров и вперёд, делать измерения, строить точки :)
Я уже молчу, что для многопоточных систем на многопроцессорных машинах, вообще, будет ожидать крах всех ожиданий en.wikipedia.org/wiki/Amdahl's_law.
>Я не совсем понял, что это «нисходящие», «восходящие» bottleneck?
Статью перечитайте, там это объясняется. Если останется непонятным, объясню подробнее.
>Это похоже на псевдонаучные спекуляции («Принципиально необнаруживаемый»).
Да, именно принципиально необнаруживаемый на медленном железе. Пример. Мы ожидаем, что увеличение кол-ва ядер процессора в 4 раза даст увеличение производительности в 3 раза. (Сейчас неважно, исходя из каких соображений мы именно так ожидаем.) А в синхронизации потоков у нас некий bottleneck, который помешает такому увеличению. Можно ли обнаружить его на одноядерном проце?
>И так надо искать параметр или группу, который сможет более-менее линейно увеличивать скорость.
>Эта задача называется регрессионный анализ. Выделяете группу параметров и вперёд, делать измерения,
>строить точки :)
Нетривиальная задача, требующая нескольких точек, т.е. измерений на нескольких тестовых кластерах с разной производительностью. Проще и, главное, надёжнее просто мерять на системе, примерно равной продакшну.
>Я уже молчу, что для многопоточных систем на многопроцессорных машинах, вообще,
>будет ожидать крах всех ожиданий
Вот именно.
Статью перечитайте, там это объясняется. Если останется непонятным, объясню подробнее.
>Это похоже на псевдонаучные спекуляции («Принципиально необнаруживаемый»).
Да, именно принципиально необнаруживаемый на медленном железе. Пример. Мы ожидаем, что увеличение кол-ва ядер процессора в 4 раза даст увеличение производительности в 3 раза. (Сейчас неважно, исходя из каких соображений мы именно так ожидаем.) А в синхронизации потоков у нас некий bottleneck, который помешает такому увеличению. Можно ли обнаружить его на одноядерном проце?
>И так надо искать параметр или группу, который сможет более-менее линейно увеличивать скорость.
>Эта задача называется регрессионный анализ. Выделяете группу параметров и вперёд, делать измерения,
>строить точки :)
Нетривиальная задача, требующая нескольких точек, т.е. измерений на нескольких тестовых кластерах с разной производительностью. Проще и, главное, надёжнее просто мерять на системе, примерно равной продакшну.
>Я уже молчу, что для многопоточных систем на многопроцессорных машинах, вообще,
>будет ожидать крах всех ожиданий
Вот именно.
Я просто хотел сказать, что фразы «Коэффициент пересчета» надо запретить к употреблению, как и «Пропускная способность на ядро», одно дело, когда их употребляют менеджеры, но другое дело программисты.
Масштабирование это крайне сложная функция и она далеко не всегда линейная (коэффициент применим только к линейным функциям), во вторых не обходимо определить параметры этой функции, а они для каждого приложения специфичны. Одним приложениям нужна память для масштабирования другим нет.
«Коэфициент пересчета» — это не подводный камень, а просто неправильный подход.
Масштабирование это крайне сложная функция и она далеко не всегда линейная (коэффициент применим только к линейным функциям), во вторых не обходимо определить параметры этой функции, а они для каждого приложения специфичны. Одним приложениям нужна память для масштабирования другим нет.
«Коэфициент пересчета» — это не подводный камень, а просто неправильный подход.
Камень 1-й. Коэффициент пересчёта
Изначально практически ошибка. Вы используете AWS. А вы в курсе что у вас на физической машинке есть соседи? Они могут аффектить. На процессоре есть лишние context switch, которые очищают L1/L2 кэши и приходится их набирать заново. Из-за этого во время нагрузочного тестирования у вас показатели могут быть сильно занижены. В принципе, если вы собираетесь использовать AWS как хостинг в production, то да, это имеет смысл. Если машинки отдельные, то и выделяйте отдельные машинки на тестирование. Единый коэффициент пересчёта это миф. В жизни, если у вас есть проц. с двумя ядрами, а в проде будет 4, то это не означает что производительность будет вдвое выше. Между двумя и четырьмя ядрами может сидеть ЕЩЕ ОДИН боттлнек, а котором вы даже не подозреваете.
Камень 2-й. Тестирующее приложение
Легко решаемо. Устраивайте тесты на разладку, т.е. линейно-возрастающий тест пока тестируемый сервис не упадет. Когда падает, смотрите на системные метрики, метрики приложения, на все, что может показать что сервис не справляется. Если такой метрики вы не видите, то можете помониторить и нагрузочную станцию, возможно боттлнек там и часто простым мониторингом можно обойтись:) Используйте не один инструмент подачи нагрузки на весь проект, а эффективный и тот, который справляется для данного участка всей сложной схемы.
Камень 3-й. Чёрный ящик
Вот с таким подходом нужно знать грань. Если обстреливаемый сервис внутри сложный, то лучше как-то комбинировать методы. Устройте обстрел в «Черный ящик», найдите боттлнек, пострайтесь увеличить его производительность уже стреляя напрямую и исследуя напрямую, снова возвращайтесь в общей схеме и т.п. Чтобы стрелять в Черный ящик, нужен уже полностью готовый стенд, что не всегда возможно. Обстреливая сервис по частям парк машин нужен меньший, а исследования на порядок проще.
Удачи в нагрузочном тестировании!:)
>Тестовая сюита
test suite?
test suite?
да
это скорее набор или комплект, а не сюита таки :)
www.google.ru/#hl=en&newwindow=1&tbo=d&sclient=psy-ab&q=%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D0%B0%D1%8F+%D1%81%D1%8E%D0%B8%D1%82%D0%B0&oq=%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D0%B0%D1%8F+%D1%81%D1%8E%D0%B8%D1%82%D0%B0&gs_l=hp.3...1303.4602.0.5185.14.12.0.2.2.0.152.1061.10j2.12.0.les%3B..0.0...1c.1.2.hp.uESWHWs8u5k&pbx=1&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&bvm=bv.42080656,d.bGE&fp=3037fc703001db27&biw=1280&bih=886
Вы что мне хотите показать сколько на свете есть безграмотных людей?
Тестовый комплект 1,410,000 results (0.15 seconds)
Тестовый набор 949,000 results (0.19 seconds)
Тестовая сюита 24,000 results (0.43 seconds)
А еще посмотрите что есть сюита на французском и в каких областях это слово имеет применение в русском
Тестовый комплект 1,410,000 results (0.15 seconds)
Тестовый набор 949,000 results (0.19 seconds)
Тестовая сюита 24,000 results (0.43 seconds)
А еще посмотрите что есть сюита на французском и в каких областях это слово имеет применение в русском
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тестирование производительности: подводные камни