Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Павел Петлинский (Rambler&Co) - Why Benchmarking Sucks?

Павел Петлинский (Rambler&Co) - Why Benchmarking Sucks?

Доклад с конференции Moscow Python Conf 2016 (http://conf.python.ru)
Видео: https://conf.python.ru/why-benchmarking-sucks/

Что же это за метрика - “производительность”? Почему одни бенчмарки плохие, другие еще хуже. На что стоит обращать внимание, чтобы сделать корректные замеры производительности.

Павел Петлинский - системный архитектор в Rambler&Co. Любит читать исходники, функциональное программирование, асинхронность, unix way и open source. Занимается разработкой высоконагруженных распределенных приложений. Программирует на Python более 10 лет.

Moscow Python Meetup

October 12, 2016
Tweet

More Decks by Moscow Python Meetup

Other Decks in Programming

Transcript

  1. 40 50+ 700 1700+ млн человек суммарная аудитория группы количество

    изданий,
 сервисов и проектов разработчиков человек в хорошей компании
  2. Контакты В группе компаний Rambler&Co всегда есть открытые вакансии для

    тех, кто хочет профессионально расти и развиваться, занимаясь тем, что по-настоящему нравится [email protected] www.rambler-co.ru/jobs
  3. Эксперимент • Бенчмарк - это эксперимент • Релевантность - учитывает

    реальный сценарий работы • Воспроизводимость - дает одни и те же результаты • Измеримость - исчислимые метрики 9
  4. Метрики • Throughput / Bandwidth - количество работы, выполненной системой

    в единицу времени (MB/sec, transaсtions/sec, requests/sec etc.) • Latency / Response Time - время отдельной операции/ задержка между стимулом и реакцией • Прочие метрики - потребление памяти, IOPS, MTTR 10
  5. Bandwidth vs Latency • Throughput / Bandwidth • достаточно легко

    измерить • скрывает большие задержки • Latency / Response Time • трудно измерить :-((( • нужно мерить отдельные события 11
  6. SpeedUp - A в N раз быстрее B • Speed

    Up - всегда положительный • A быстрее B в 50 раз ~ B медленнее А в 0,02 раза Speed Up vs Boost 12
  7. Speed Up vs Boost (пример) 14 Проект SpeedUp Boost Старт

    1.0x 0% Релиз #1 1.5x +50% Релиз #2 0.82x -18% Релиз #3 1.21x +21% Вопрос - стало лучше или хуже?
  8. Speed Up vs Boost (пример) 15 Проект SpeedUp Boost Старт

    1.0x 0% Релиз #1 1.5x +50% Релиз #2 0.82x -18% Релиз #3 1.21x +21% Вопрос - стало лучше или хуже? 0.82*1.21 = 0.9922 ( замедление ~1% )
  9. Warmup 17 • Мы работаем с динамическими системами. • Переходных

    процессов в них куча. • Всегда проверяйте, вышла система на Steady State или нет.
  10. В этих ваших интернетах “using a 16 core machine on

    GCE with 60GB of RAM” “separate m4.xlarge amazon instance with the ubuntu 14.04 x64” “executed on 4 AWS c4.2xlarge instances used as servers and 1 AWS c4.2xlarge instance used as the client” 20
  11. Погрешность измерений 23 • Сколько времени измеряется время? • А

    какова гранулярность? • А сколько времени занимает отправка запроса в браузере? • Каково время отправки через loopback? • Сколько стоит формирование запроса? • А еще в инструментах бывают баги…
  12. Средняя задержка - зло 28 • В природе нет дискретных

    величин • Есть распределение величин • Нужно рассматривать отдельные события
  13. 95 перцентиль - решение всех проблем Какова вероятность, что сделав

    N запросов мы попадем в 5 процентов неудачников? 1 0.0500 2 0.0975 3 0.1426 4 0.1855 5 0.2262 6 0.2649 … 20 0.6415 31
  14. 99.9 перцентиль 32 1 0.0100 2 0.0199 3 0.0297 4

    0.0394 5 0.0490 6 0.0585 … 20 0.1821