Wydajność
Techniki optymalizacji
Architektura bota została zaprojektowana wokół lekkiego wykonania i minimalnych operacji blokujących. Większość krytycznych systemów działa asynchronicznie lub w izolowanych wątkach, aby logika transakcyjna pozostała responsywna nawet pod dużym obciążeniem.
Infrastruktura rozdziela obowiązki na dedykowane moduły:
- •Silnik transakcyjny
- •Warstwę komunikacji TCP
- •Integrację z Telegramem
- •Warstwę trwałości
- •System logowania
- •Wątki robocze w tle
Zapobiega to blokowaniu wykonywania zleceń lub analizy rynku przez wolne operacje.
Na przykład, trwałość jest obsługiwana przez asynchroniczny system oparty na kolejce. Aktualizacje stanu są przekazywane do pracownika tła zamiast bezpośredniego zapisu na dysk podczas operacji transakcyjnych. To drastycznie zmniejsza narzut wykonawczy podczas aktywnego handlu.
System logowania jest również zoptymalizowany do użytku produkcyjnego:
- •Oddzielne handlery konsoli i plików
- •Rotujące pliki logów
- •Niezależne przekazywanie logów TCP
- •Konfigurowalne poziomy logowania
Bot unika nadmiernych punktów synchronizacji i używa lekkiego wielowątkowości tylko tam, gdzie jest to konieczne. Wątki robocze w tle działają jako wątki demona, umożliwiając głównej pętli strategii skupienie się na wykonaniu rynkowym.
Dodatkowe techniki optymalizacji stosowane w projekcie obejmują:
- •Deduplikację kolejek dla zapisów trwałości
- •Atomowe zastępowanie plików zamiast pełnych przepisywań
- •Instancje loggerów wielokrotnego użytku
- •Trwałe połączenia TCP
- •Jawne importy modułów z kontrolowanym
PYTHONPATH - •Niezależne restartowalne usługi
- •Minimalne interwały blokujące sleep
Architektura jest celowo modułowa, aby użytkownicy mogli zastąpić logikę strategii bez odbudowywania warstwy infrastruktury.
Zmniejszenie użycia API
Efektywne wykorzystanie API jest krytyczne dla każdego poważnego systemu transakcyjnego.
Platforma została zaprojektowana tak, aby zmniejszyć niepotrzebne żądania do giełdy, zachowując jednocześnie szybką szybkość reakcji.
Kilka decyzji infrastrukturalnych pomaga zminimalizować obciążenie API:
Inteligentna trwałość stanu
Zamiast ciągłego ponownego pobierania danych z giełdy po każdym restarcie, bot przechowuje wewnętrzny stan transakcyjny lokalnie za pomocą warstwy trwałości.
Pozwala to na:
- •Odzyskiwanie pozycji
- •Śledzenie zleceń
- •Kontynuację strategii po restarcie
- •Zmniejszone żądania synchronizacji
Bot nie musi odbudowywać pełnego stanu z giełdy za każdym razem, gdy się uruchamia.
Wewnętrzne routowanie poleceń
System Telegram komunikuje się przez lokalną warstwę TCP, zamiast sondować zewnętrzne usługi pod kątem stanu bota.
Polecenia takie jak:
- •
starttrading - •
stoptrading - •
buy - •
sell - •
getstatus
są kierowane wewnętrznie między modułami z prawie zerowym narzutem.
Pozwala to uniknąć niepotrzebnej zewnętrznej komunikacji API i utrzymuje infrastrukturę lekką.
Kontrolowane poziomy logowania
Poziom szczegółowości logowania można skonfigurować niezależnie dla:
- •Wyjścia konsoli
- •Logowania do pliku
- •Ogólnego poziomu loggera
Zapobiega to nadmiernym operacjom debugowania w środowiskach produkcyjnych.
Ciężkie logowanie debugowania może znacznie obniżyć wydajność w systemach o wysokiej częstotliwości, dlatego konfigurowalne filtrowanie logów jest ważne.
Logika lokalnego odzyskiwania
Systemy odzyskiwania po awarii i automatycznego restartu pomagają zmniejszyć powtarzające się żądania synchronizacji startowej.
Zamiast ręcznie odbudowywać całe środowisko wykonawcze po awariach, bot szybko przywraca działanie przy użyciu utrwalonego stanu i pętli wykonawczych Watchdog.
Wykonanie o niskim opóźnieniu
Wykonanie o niskim opóźnieniu jest osiągane dzięki prostocie infrastruktury i izolacji procesów.
Projekt unika niepotrzebnych frameworków i ciężkich warstw orkiestracji. System transakcyjny działa jako bezpośrednie procesy Pythona z minimalnym oprogramowaniem pośredniczącym między logiką strategii a wykonaniem.
Kluczowe wybory projektowe skupione na niskim opóźnieniu obejmują:
Dedykowany proces transakcyjny
Bot transakcyjny działa niezależnie od interfejsu Telegram.
Oznacza to:
- •Ruch Telegram nie może zablokować logiki transakcyjnej
- •Opóźnienia w wiadomościach nie wpływają na wykonanie
- •Zewnętrzne powiadomienia pozostają izolowane
Nawet jeśli Telegram stanie się niedostępny, silnik transakcyjny kontynuuje działanie.
Trwała komunikacja TCP
Komunikacja między modułami wykorzystuje trwałą warstwę TCP zamiast tworzenia tymczasowych procesów lub używania wolnych mechanizmów IPC.
Zapewnia to:
- •Szybkie dostarczanie poleceń
- •Lekki routing wiadomości
- •Strumienie logów w czasie rzeczywistym
- •Komunikację o minimalnym narzucie
Logi z silnika transakcyjnego są przesyłane bezpośrednio do bota Telegram przez potok TCP, umożliwiając monitorowanie w czasie rzeczywistym bez blokowania wykonania.
Architektura wątków tła
Kilka operacji działa niezależnie od głównej pętli strategii:
- •Zapisy trwałości
- •Komunikacja TCP
- •Obsługa poleceń Telegram
- •Przekazywanie logów
- •Wątki robocze odzyskiwania
Zapobiega to przerywaniu wykonywania transakcji przez wolne operacje I/O.
Infrastruktura automatycznego restartu
Skrypt
Minimalizuje to przestoje i utrzymuje niezwykle niskie opóźnienie odzyskiwania.
Zamiast wymagać ręcznej interwencji, infrastruktura automatycznie przywraca usługi w ciągu kilku sekund.
Minimalny stos wykonawczy
System celowo unika:
- •Ciężkich frameworków webowych
- •Narzutu orkiestracji kontenerów
- •Serwerów baz danych
- •Złożonych brokerów wiadomości
- •Dużych łańcuchów zależności
Rezultatem jest lekkie środowisko wykonawcze skupione wyłącznie na wydajności transakcyjnej i stabilności operacyjnej.
Infrastruktura działa jako szybka podstawa, na której użytkownicy mogą implementować własne algorytmy transakcyjne, zachowując jednocześnie w pełni zintegrowane, profesjonalnej klasy systemy trwałości, logowania, monitorowania, restartu i odzyskiwania oraz komunikacji.