“Мікросервіси відомі своєю складністю у бенчмаркінгу, оскільки всі рухомі частини роблять їх статистично непередбачуваними, подібно до машин Формули 1.”
Ви можете сказати, що це тому, що ми можемо бенчмаркувати мікросервіси лише в контрольованому середовищі, так само як і вітрові труби для машин Формули 1. Але вітрові труби неймовірно складні. Наприклад, McLaren витратила 4 роки на створення власної вітрової труби. Якщо порівняти це з тестуванням продуктивності, чи є у нас такі інструменти/системи для оцінки продуктивності чогось загалом?
Перша основа бенчмаркінгу полягає в тому, що ваш бенчмарк завжди помилковий. Дійсно, це наука — налаштувати реалістичні умови, повторно запускати і вимірювати багато разів, а також визначити зовнішні фактори, які стабільно впливають на результати. І справді, існують тисячі способів, як простий підхід до бенчмаркінгу може піти не так.
Наприклад:
- Один раз A показав кращий результат, ніж B, коли я вимірював A перед B, але тренд змінився, коли я помістив B перед A або щось подібне (можливо, навпаки? Я не знаю). Не розумію, чому так сталося.
- Іншим разом результати змінилися сильно, коли я перезапустив бенчмарк в іншому проекті з майже ідентичним (але трохи зміненим) вихідним кодом на тій самій платформі/компілері/щось інше. Не розумію, чому так сталося.
- В іншому випадку результати змінилися, коли я перезапустив бенчмарк через кілька років, з 100% ідентичним вихідним кодом на тій самій платформі/щось інше. Можливо, машина стала старшою, і продуктивність знизилась?
- Статистика реального світу для вхідних даних може бути дуже дивною, оскільки A виграє перед B з точки зору добре виглядаючої ймовірнісної моделі, але B виграє перед A за реальними даними. Або, принаймні, теоретично псевдовипадкові генератори мають певні статистичні дефекти, які можуть впливати на результат. Хто знає.
- Залежно від того, де в проекті розміщений код для алгоритмів, компілятор може приймати різні рішення щодо інлайнів, що може мати каскадний ефект на кінцеву продуктивність.
- Якщо алгоритм, який ви вимірюєте, дуже швидкий, ви не можете надійно виміряти час одного запуску. Циклічне виконання (особливо з тим самим вхідним даними) може дозволити CPU робити кращі й кращі прогнози гілок, спотворюючи результат на користь алгоритмів з великою кількістю гілок.
Можливо, ви думаєте — Яке рішення? Я не мав можливості спробувати це (хоча той самий підхід можна застосувати до будь-якої системи, яку ви намагаєтесь бенчмаркнути).
- Дано N алгоритмів та M вхідних даних, виберіть достатньо велике число, S.
- Випадковим чином виберіть S екземплярів (з дозволом повторень) з усіх NM комбінацій алгоритму та вхідних даних і виміряйте загальний час, необхідний для виконання всіх S вибраних пар.
- Повторіть крок 2 для T разів, для достатньо великого T. Тоді ми отримаємо систему лінійних рівнянь, що складається з T рівнянь та NM + 1 невідомих (+1 для “базових накладних витрат”).
- Розв'яжіть це рівняння (в сенсі мінімальної середньоквадратичної похибки), тоді ми отримаємо середній час, необхідний для виконання кожного з N алгоритмів з кожним з M вхідних даних.
- Щоб уникнути неймовірної кількості обчислень, нам може знадобитися випадковим чином розподілити M вхідних даних, щоб зменшити обчислювальну розмірність.
Перекладено з: Chronicles of Benchmarking