Продуктивність
Техніки оптимізації
Архітектура бота розроблена з акцентом на легке виконання та мінімізацію блокуючих операцій. Більшість критичних систем працюють асинхронно або в ізольованих потоках, щоб торгова логіка залишалася чуйною навіть під високим навантаженням.
Інфраструктура розділяє обов'язки на спеціалізовані модулі:
- •Торговий рушій
- •Шар TCP комунікації
- •Інтеграція з Telegram
- •Шар збереження даних (Persistence)
- •Система логування
- •Фонові воркери
Це запобігає блокуванню виконання ордерів або аналізу ринку через повільні операції.
Наприклад, збереження даних обробляється через асинхронну систему на основі черг. Оновлення стану передаються у фоновий воркер замість прямого запису на диск під час торгових операцій. Це значно знижує витрати ресурсів на виконання під час активної торгівлі.
Система логування також оптимізована для використання у продакшені:
- •Окремі обробники для консолі та файлів
- •Ротація файлів логів
- •Незалежне пересилання логів через TCP
- •Гнучке налаштування рівнів логування
Бот уникає надмірних точок синхронізації та використовує легкі потоки лише там, де це необхідно. Фонові воркери працюють як потоки-демони, що дозволяє основному циклу стратегії залишатися сфокусованим на виконанні ринкових операцій.
Додаткові методи оптимізації, що використовуються в проєкті, включають:
- •Дедуплікацію черг для збереження даних
- •Атомарну заміну файлів замість повного перезапису
- •Повторне використання екземплярів логера
- •Постійні TCP з'єднання
- •Явні імпорти модулів з контрольованим
PYTHONPATH - •Незалежні сервіси з можливістю перезапуску
- •Мінімальні інтервали блокування сну
Архітектура навмисно зроблена модульною, щоб користувачі могли замінювати логіку стратегії без необхідності перебудови інфраструктурного рівня.
Зменшення використання API
Ефективне використання API має вирішальне значення для будь-якої серйозної торгової системи.
Платформа розроблена так, щоб зменшити кількість непотрібних запитів до біржі, зберігаючи при цьому високу швидкість реакції.
Декілька інфраструктурних рішень допомагають мінімізувати навантаження на API:
Розумне збереження стану
Замість постійного повторного отримання даних з біржі після кожного перезапуску, бот зберігає внутрішній стан торгівлі локально, використовуючи рівень збереження (persistence).
Це дозволяє:
- •Відновлювати позиції
- •Відстежувати ордери
- •Продовжувати роботу стратегії після перезапуску
- •Зменшити кількість запитів на синхронізацію
Боту не потрібно повністю відновлювати стан з біржі при кожному запуску.
Внутрішня маршрутизація команд
Система Telegram обмінюється даними через локальний TCP шар, замість того, щоб опитувати зовнішні сервіси про стан бота.
Такі команди, як:
- •
starttrading - •
stoptrading - •
buy - •
sell - •
getstatus
маршрутизуються внутрішньо між модулями з майже нульовими витратами ресурсів.
Це дозволяє уникнути непотрібної комунікації через зовнішні API та зберігає інфраструктуру легкою.
Контрольовані рівні логування
Деталізацію логування можна налаштовувати незалежно для:
- •Консольного виводу
- •Запису у файл
- •Загального рівня логера
Це запобігає надмірним операціям відлагодження у продакшен-середовищах.
Інтенсивне відлагоджувальне логування може значно знизити продуктивність у високочастотних системах, тому можливість налаштування фільтрації логів є важливою.
Локальна логіка відновлення
Системи відновлення після збоїв та автоматичного перезапуску допомагають зменшити кількість повторних запитів синхронізації при старті.
Замість того, щоб вручну відновлювати все середовище виконання після збоїв, бот швидко відновлюється, використовуючи збережений стан і цикли виконання watchdog-скриптів.
Виконання з низькою затримкою
Виконання з низькою затримкою (Low latency) досягається завдяки простоті інфраструктури та ізоляції процесів.
Проєкт уникає непотрібних фреймворків і важких шарів оркестрації. Торгова система працює як прямі Python-процеси з мінімальною кількістю проміжного ПЗ (middleware) між логікою стратегії та виконанням.
Ключові дизайнерські рішення, орієнтовані на мінімізацію затримок, включають:
Виділений процес торгівлі
Торговий бот працює незалежно від інтерфейсу Telegram.
Це означає:
- •Трафік Telegram не може заморозити торгову логіку
- •Затримки у обміні повідомленнями не впливають на виконання
- •Зовнішні сповіщення залишаються ізольованими
Навіть якщо Telegram стане недоступним, торговий рушій продовжуватиме працювати.
Постійна TCP комунікація
Для обміну даними між модулями використовується постійний TCP шар, замість створення тимчасових процесів або використання повільних механізмів міжпроцесної взаємодії (IPC).
Це забезпечує:
- •Швидку доставку команд
- •Легку маршрутизацію повідомлень
- •Потоки логів у реальному часі
- •Зв'язок з мінімальними накладними витратами
Логи з торгового рушія пересилаються безпосередньо в Telegram бот через TCP конвеєр, що дозволяє здійснювати моніторинг майже в реальному часі без блокування виконання.
Архітектура фонових потоків
Декілька операцій виконуються незалежно від основного циклу стратегії:
- •Збереження даних (persistence)
- •TCP комунікація
- •Обробка команд Telegram
- •Пересилання логів
- •Воркери відновлення
Це запобігає перериванню виконання торгів повільними операціями вводу/виводу.
Інфраструктура автоматичного перезапуску
Watchdog-система
Це мінімізує час простою та підтримує затримку відновлення на надзвичайно низькому рівні.
Замість того, щоб вимагати ручного втручання, інфраструктура автоматично відновлює роботу сервісів за лічені секунди.
Мінімальний стек виконання
Система навмисно уникає:
- •Важких веб-фреймворків
- •Накладних витрат на контейнерну оркестрацію
- •Серверів баз даних
- •Складних брокерів повідомлень
- •Великих ланцюжків залежностей
В результаті ми отримуємо легке середовище виконання, повністю зосереджене на продуктивності торгівлі та стабільності роботи.
Інфраструктура виступає у ролі високошвидкісного фундаменту, на якому користувачі можуть реалізовувати власні торгові алгоритми, зберігаючи при цьому повністю інтегровані системи збереження даних професійного рівня, логування, моніторинг, відновлення після перезапуску та комунікацію.