Почему не стоит "слепо" доверять инструментам и отчетам
#testing #performance
История о том, что "зеленые отчеты" могут скрывать проблемы.
#testing #performance
История о том, что "зеленые отчеты" могут скрывать проблемы.
Telegraph
Почему не стоит "слепо" доверять инструментам и отчетам
Сегодня я расскажу небольшую историю, о том почему же не стоит доверять результатам тестов.
👍3
Hardcore у п'ятницю: Перша ремарка про перфоманс блокчейн систем
#testing #performance #blockchain
Цього тижня я тільки-но почав досліджувати питання перфомансу блокчейн систем. А саме - як та що вимірювати.
Ось що я встиг зрозуміти.
Блокчейн систему (як дуже спеціалізований вид розподілених систем) не можна тестувати та вимірювати звичайними метриками та засобами до яких ми звикли. Тобто не буде дуже правильно ставити питання “скільки TPS (transaction per second) може витримати система?” (а люди все ще запитують)
Чому? Бо блокчейн веде себе зовсім по-іншому. В звичайній системі (наприклад у веб додатку) більшість запитів повинні отримати відповідь через деякий час. Чим більше запитів від користувачів, тим більше ресурсів бекенду задіяні в обробці цих засобів.
Для того, щоб обробляти більше запитів - ми просто додаємо більше “машин” для обробки. (Наприклад автоматично через auto-scaling).
В блокчейні такий підхід не працює.
Кожен вузол в блокчейні може обробляти деяку кількість запитів. Причому запити в блокчейні - це звичайні транзакції. Коли транзакцій стає більше, ніж влазить у mempool вузла, нові транзакції не будуть оброблятись.
Вузлу треба час, багато часу:
- Вузлу треба час, щоб зрозуміти - чи може він створити новий блок в PoS
- Або вузлу треба час, щоб підібрати потрібний хеш для блоку в PoW консенсусі.
- Треба час, для того, щоб згідно алгоритму обрати з пулу транзакції та створити новий блок.
- Вузлу треба час, щоб обмінятися з іншими вузлами інформацією про новий блок.
- Вузлу треба час, щоб вирішити конфлікти, якщо одночасно створені декілька блоків.
- Вузлам в системі потрібен час, щоб більшість з них погодились на новий блок.
В окремому випадку потрібно зачекати, поки транзакція стане “стабільною”. Це може бути N блоків поверх того, в якому ця транзакція опинилась або інший варіант алгоритму. Тільки після цього можна відправити дійсно правдивий респонс користувачеві про те, що його транзакція успішна.
То ж підвищити швидкість обробки транзакцій (тобто “перфоманс” блокчейну) не можливо простим додаванням більшої кількості вузлів. Бо вузлам потрібен час, щоб комунікувати між собою та досягти консенсусу.
Один з варіантів оцінки швидкості - це наскільки швидко буде транзакція оброблена, включена в блок та стане стабільною. Тобто block propagation time.
Попереду в мене ще багато відкриттів. Продовжую дослідження.
#testing #performance #blockchain
Цього тижня я тільки-но почав досліджувати питання перфомансу блокчейн систем. А саме - як та що вимірювати.
Ось що я встиг зрозуміти.
Блокчейн систему (як дуже спеціалізований вид розподілених систем) не можна тестувати та вимірювати звичайними метриками та засобами до яких ми звикли. Тобто не буде дуже правильно ставити питання “скільки TPS (transaction per second) може витримати система?” (а люди все ще запитують)
Чому? Бо блокчейн веде себе зовсім по-іншому. В звичайній системі (наприклад у веб додатку) більшість запитів повинні отримати відповідь через деякий час. Чим більше запитів від користувачів, тим більше ресурсів бекенду задіяні в обробці цих засобів.
Для того, щоб обробляти більше запитів - ми просто додаємо більше “машин” для обробки. (Наприклад автоматично через auto-scaling).
В блокчейні такий підхід не працює.
Кожен вузол в блокчейні може обробляти деяку кількість запитів. Причому запити в блокчейні - це звичайні транзакції. Коли транзакцій стає більше, ніж влазить у mempool вузла, нові транзакції не будуть оброблятись.
Вузлу треба час, багато часу:
- Вузлу треба час, щоб зрозуміти - чи може він створити новий блок в PoS
- Або вузлу треба час, щоб підібрати потрібний хеш для блоку в PoW консенсусі.
- Треба час, для того, щоб згідно алгоритму обрати з пулу транзакції та створити новий блок.
- Вузлу треба час, щоб обмінятися з іншими вузлами інформацією про новий блок.
- Вузлу треба час, щоб вирішити конфлікти, якщо одночасно створені декілька блоків.
- Вузлам в системі потрібен час, щоб більшість з них погодились на новий блок.
В окремому випадку потрібно зачекати, поки транзакція стане “стабільною”. Це може бути N блоків поверх того, в якому ця транзакція опинилась або інший варіант алгоритму. Тільки після цього можна відправити дійсно правдивий респонс користувачеві про те, що його транзакція успішна.
То ж підвищити швидкість обробки транзакцій (тобто “перфоманс” блокчейну) не можливо простим додаванням більшої кількості вузлів. Бо вузлам потрібен час, щоб комунікувати між собою та досягти консенсусу.
Один з варіантів оцінки швидкості - це наскільки швидко буде транзакція оброблена, включена в блок та стане стабільною. Тобто block propagation time.
Попереду в мене ще багато відкриттів. Продовжую дослідження.
👍21
Benchmarking: You're Doing It Wrong
#testing #performance #video
Сьогодні ранок вівторка, навкруги літо та спека, але цікавих матеріалів менше не стає.
Тому пропоную переглянути доповідь по дуже базовим речам з тестування навантаження. Більше про підходи та про те, чому такий вид тестування складний.
На дату не дивіться - бо такі відео довго залишаються актуальними.
#testing #performance #video
Сьогодні ранок вівторка, навкруги літо та спека, але цікавих матеріалів менше не стає.
Тому пропоную переглянути доповідь по дуже базовим речам з тестування навантаження. Більше про підходи та про те, чому такий вид тестування складний.
На дату не дивіться - бо такі відео довго залишаються актуальними.
YouTube
"Benchmarking: You're Doing It Wrong" by Aysylu Greenberg
Knowledge of how to set up good benchmarks is invaluable in understanding performance of the system. Writing correct and useful benchmarks is hard, and verification of the results is difficult and prone to errors. When done right, benchmarks guide teams to…
❤7
🐍Is Python Really That Slow? 🚤
#python #performance
Доволі цікаве порівняння швидкості між Python (CPython та PyPy рантайм різних версій), Node.js та Rust. Порівнювали на базових алгоритмах, типу Фібоначчі чи сортування.
Здається, переможець очевидний.
Треба відмітити, що PyPy рантайм останньої версії значно покращив свої показники та став навіть краще, ніж node. Але до Rust ще рости й рости.
Для тих, хто хоче дізнатись різницю між CPython та PyPy - маю окрему статтю.
#python #performance
Доволі цікаве порівняння швидкості між Python (CPython та PyPy рантайм різних версій), Node.js та Rust. Порівнювали на базових алгоритмах, типу Фібоначчі чи сортування.
Здається, переможець очевидний.
Треба відмітити, що PyPy рантайм останньої версії значно покращив свої показники та став навіть краще, ніж node. Але до Rust ще рости й рости.
Для тих, хто хоче дізнатись різницю між CPython та PyPy - маю окрему статтю.
Miguelgrinberg
Is Python Really That Slow?
My standard response when someone asks me how I deal with Python being such a slow language is that Python is by far the fastest to write, cleanest, more maintainable programming language I know, and…
👍11❤1🤮1