Продуктивність

Розуміння продуктивності

etcd забезпечує стабільну, стійку високу продуктивність. Два фактори визначають продуктивність: затримка та пропускна здатність. Затримка — це час, необхідний для завершення операції. Пропускна здатність — це загальна кількість операцій, виконаних за певний період часу. Зазвичай середня затримка збільшується зі збільшенням загальної пропускної здатності, коли etcd приймає одночасні запити клієнтів. У звичайних хмарних середовищах, таких як стандартний n-4 у Google Compute Engine (GCE) або аналогічний тип машини на AWS, кластер etcd з трьох учасників завершує запит менш ніж за одну мілісекунду при невеликому навантаженні та може виконувати понад 30 000 запитів на секунду при великому навантаженні.

etcd використовує алгоритм консенсусу Raft для реплікації запитів між учасниками та досягнення згоди. Продуктивність консенсусу, особливо затримка коміту, обмежена двома фізичними обмеженнями: затримкою мережевого вводу-виводу та затримкою дискового вводу-виводу. Мінімальний час для завершення запиту etcd — це час проходження (RTT, Round Trip Time) між учасниками плюс час, необхідний для fdatasync, щоб зафіксувати дані на постійне зберігання. RTT у межах датацентра може становити кілька сотень мікросекунд. Типовий RTT у межах Сполучених Штатів становить близько 50 мс, а між континентами може бути повільним до 400 мс. Типова затримка fdatasync для диска (HDD), становить близько 10 мс. Для SSD затримка часто менша за 1 мс. Щоб збільшити пропускну здатність, etcd обʼєднує кілька запитів разом і подає їх до Raft. Ця політика обʼєднання дозволяє etcd досягати високої пропускної здатності, попри велике навантаження.

Існують інші підсистеми, які впливають на загальну продуктивність etcd. Кожен серіалізований запит etcd повинен пройти через сховище MVCC на основі boltdb, яке зазвичай займає десятки мікросекунд для завершення. Періодично etcd інкрементально знімає знімки своїх нещодавно застосованих запитів, обʼєднуючи їх з попереднім знімком на диску. Цей процес може призвести до стрибка затримки. Хоча це зазвичай не є проблемою на SSD, це може подвоїти спостережувану затримку на HDD. Так само, поточні ущільнення можуть вплинути на продуктивність etcd. На щастя, вплив часто незначний, оскільки ущільнення розподілене так, щоб не конкурувати за ресурси зі звичайними запитами. Система RPC, gRPC, надає etcd добре визначений, розширюваний API, але також вводить додаткову затримку, особливо для локальних читань.

Тестування продуктивності

Тестування продуктивності etcd можна виконати за допомогою CLI інструменту benchmark, що входить до складу etcd.

Для деяких базових показників продуктивності ми розглядаємо кластер etcd з трьох учасників з наступною апаратною конфігурацією:

• Google Cloud Compute Engine
• 3 машини з 8 vCPU + 16GB памʼяті + 50GB SSD
• 1 машина (клієнт) з 16 vCPU + 30GB памʼяті + 50GB SSD
• Ubuntu 17.04
• etcd 3.2.0, go 1.8.3

З цією конфігурацією etcd може приблизно записувати:

Приклад команд:

# запис до лідера
benchmark --endpoints=${HOST_1} --target-leader --conns=1 --clients=1 \
    put --key-size=8 --sequential-keys --total=10000 --val-size=256
benchmark --endpoints=${HOST_1} --target-leader  --conns=100 --clients=1000 \
    put --key-size=8 --sequential-keys --total=100000 --val-size=256

# запис до всіх учасників
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    put --key-size=8 --sequential-keys --total=100000 --val-size=256

Запити на лінійне читання проходять через кворум учасників кластера для досягнення консенсусу та отримання найсвіжіших даних. Запити на серіалізоване читання дешевші, ніж лінійні читання, оскільки вони обслуговуються будь-яким окремим учасником etcd, а не кворумом учасників, в обмін на можливість отримання застарілих даних. etcd може читати:

Приклад команд:

# Запити на читання з одним зʼєднанням
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \
    range YOUR_KEY --consistency=l --total=10000
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=1 --clients=1 \
    range YOUR_KEY --consistency=s --total=10000

# Багато одночасних запитів на читання
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    range YOUR_KEY --consistency=l --total=100000
benchmark --endpoints=${HOST_1},${HOST_2},${HOST_3} --conns=100 --clients=1000 \
    range YOUR_KEY --consistency=s --total=100000

Ми рекомендуємо запускати тестування продуктивності під час налаштування кластера etcd вперше в новому середовищі, щоб переконатися, що кластер досягає адекватної продуктивності; затримка та пропускна здатність кластера можуть бути чутливими до незначних відмінностей у середовищі.