Test Engineering Notes
3.81K subscribers
177 photos
2 videos
648 links
Україномовний канал про технічні аспекти тестування, розподілені системи, блокчейн.

Консультації з автоматизації, менторинг, тестові співбесіди - @al8xr
Download Telegram
What would happen if we didn't use TCP or UDP?

#engineering #rust

Невеличкий експеримент щодо використання кастомних протоколів (відмінних від TCP та UDP).

Чи будуть такий протокол обробляти провайдери - такі як Digital Ocean чи AWS?
8👍1
Rust - це не завжди швидко й ефективно

#rust #blockchain

Виявилося, що обробка транзакцій в блокчейні Solana була не те, щоб дуже ефективною. Приніс вам історію про те, як можна зменшити використання оперативної памʼяті з 2.6 Gb до 124 Mb.

В багатопотоковому світ структури типу Cow (Clone on Write) чи Arc не завжди підходять.

Є ще Bytes crate - який дозволяє ефективно клонувати не сам масив, а лишень покажчик (pointer) на нього.
13🤯4
🪲 Чому впав Cloudflare?

#bugs #sql #rust

Минулого тижня пів інтернету лежало через те, що сервіс Cloudflare впав та був недоступний якийсь час.

Але чому це сталося? Чи винні в цьому тестувальники? Чи справа в … коді на Rust?

Відповідь не така проста, як здається.

🎓 Як обробляються запити в Cloudflare

Усі запити на Cloudflare проходять через основний проксі сервер. На цьому сервері є багато модулів, що виконують перевірки безпеки для захисту від DDoS атак. Зокрема, такий модуль як Bot Management.

Bot Management - це модель машинного навчання для оцінки того, чи даний запит прийшов від бота чи від реального користувача. Модель приймає на вхід ряд параметрів (features) на основі яких будується статистика та оцінки. Так як боти змінюються дуже швидко - то й даний набір параметрів оновлюється раз у пʼять хвилин.

Чисто технічно, набір параметрів - це файл із переліком фічей, який розповсюджується по всім серверам Cloudflare.

🏫 В чому виникла помилка?

За замовчуванням, фічі отримують розподіленим запитом у базу даних “default” у кластері ClickHouse. У користувача був доступ тільки до цієї бази.

Але для покращень безпеки, розробники зробили зміну, що дає можливість працювати ще й з системними таблицями.

Зміну в налаштуваннях зробили, але … не перевірили сам SQL запит.


SELECT
name,
type
FROM system.columns
WHERE
table = 'http_requests_features'
order by name;


А цей запит не мав … фільтру по базі даних. Як результат, цей запит повертав фічі як з таблиці “default”, так і з системної таблиці.

То ж файл з фічами для Bot Management мав купу зайвих дублікатів фічей.

🕶 Ну то й що?

Виявляється, що для обробки фічей попередньо резервується оперативна памʼять. Зазвичай, у файлі було десь 60 фічей при максимумі в 200.

Але коли сталася помилка - у файлі фічей було більше ніж 200!

То ж серверу не вистачало памʼяті, щоб обробити ці фічі. Окей, не вистачило памʼяті, це погано - але чому так довго шукали проблему?

А код на Rust, який обробляє ці фічі … не обробляв таку помилку - а просто кидав базовий Error за допомогою unwrap();


pub fn fetch_features(&mut self, input: &dyn BotsInput, features: &mut Features) -> Result<(), (ErrorFlags, i32)> {
features.checksum &= 0xFFF_FFF_000_000;
features.checksum |= u64::from(self.config.checksum);
let (feature_values, _) = features
.append_with_names(&self.config.feature_names)
.unwrap();
//
}


То ж код почав видавати дуже загальну помилку.

Плюс файл із фічами швидко розлетівся по серверам - й вони також збоїли по тій же самій причині.

💡 Що можна було б зробити?

👉Більш ретельно обробляти помилки. Rust як мова програмування в цьому випадку не винен.
👉Тестувати запити на тестових серверах (включно з лімітами по памʼяті). Можна було б досліджувати як система обробляє дані великих розмірів.

❗️Більш докладно про збій можна почитати в офіційному блозі компанії.
🔥30👍53