Prestaties
Optimalisatietechnieken
De botarchitectuur is ontworpen rond lichtgewicht uitvoering en minimale blokkerende bewerkingen. De meeste kritieke systemen werken asynchroon of in geïsoleerde threads om de handelslogica responsief te houden, zelfs onder zware belasting.
De infrastructuur scheidt verantwoordelijkheden in toegewijde modules:
- •Handelsengine
- •TCP-communicatielaag
- •Telegram-integratie
- •Persistentielaag
- •Logsysteem
- •Achtergrondworkers
Dit voorkomt dat trage bewerkingen orderuitvoering of marktanalyse blokkeren.
Persistentie wordt bijvoorbeeld afgehandeld via een asynchroon wachtrijgebaseerd systeem. Statusupdates worden naar een achtergrondworker gestuurd in plaats van tijdens handelsactiviteiten direct naar schijf te schrijven. Dit vermindert de uitvoeringsoverhead tijdens actieve handel aanzienlijk.
Het logsysteem is ook geoptimaliseerd voor productiegebruik:
- •Aparte console- en bestandshandlers
- •Roterende logbestanden
- •Onafhankelijke TCP-log-doorsturing
- •Configureerbare logniveaus
De bot vermijdt overmatige synchronisatiepunten en gebruikt alleen waar nodig lichtgewicht threading. Achtergrondworkers draaien als daemon-threads, waardoor de kernstrategielus zich kan blijven richten op marktuitvoering.
Aanvullende optimalisatietechnieken die in het hele project worden gebruikt, zijn onder andere:
- •Wachtrij-deduplicatie voor persistentie-opslagen
- •Atomische bestandsvervanging in plaats van volledige herschrijvingen
- •Herbruikbare loggerinstanties
- •Permanente TCP-verbindingen
- •Expliciete module-imports met gecontroleerde
PYTHONPATH - •Onafhankelijk herstartbare services
- •Minimale blokkerende slaapintervallen
De architectuur is bewust modulair, zodat gebruikers de strategielogica kunnen vervangen zonder de infrastructuurlaag opnieuw te hoeven bouwen.
API-gebruik verminderen
Efficiënt API-gebruik is cruciaal voor elk serieus handelssysteem.
Het platform is ontworpen om onnodige exchange-verzoeken te verminderen terwijl een snelle reactiesnelheid behouden blijft.
Verschillende infrastructuurbeslissingen helpen de API-belasting te minimaliseren:
Slimme Statuspersistentie
In plaats van na elke herstart constant gegevens van de exchange op te halen, slaat de bot de interne handelstoestand lokaal op met behulp van de persistentielaag.
Dit maakt mogelijk:
- •Positieherstel
- •Ordertracking
- •Strategiecontinuatie na herstart
- •Verminderde synchronisatieverzoeken
De bot hoeft niet elke keer dat hij opstart de volledige status van de exchange opnieuw op te bouwen.
Interne Commando-routering
Het Telegram-systeem communiceert via een lokale TCP-laag in plaats van externe services te pollen voor de botstatus.
Commando's zoals:
- •
starttrading - •
stoptrading - •
buy - •
sell - •
getstatus
worden intern tussen modules gerouteerd met bijna nul overhead.
Dit vermijdt onnodige externe API-communicatie en houdt de infrastructuur lichtgewicht.
Gecontroleerde Logniveaus
De uitgebreidheid van de logging kan onafhankelijk worden geconfigureerd voor:
- •Console-uitvoer
- •Bestandslogging
- •Algemeen loggerniveau
Dit voorkomt overmatige debug-bewerkingen in productieomgevingen.
Zware debug-logging kan de prestaties aanzienlijk verminderen in hoogfrequente systemen, dus configureerbare logfiltering is belangrijk.
Lokale Herstellogica
Crashherstel en automatische herstartsystemen helpen herhaalde synchronisatieverzoeken bij het opstarten te verminderen.
In plaats van de volledige runtime-omgeving handmatig opnieuw op te bouwen na storingen, herstelt de bot snel met behulp van gepersisteerde status en watchdog-uitvoeringslussen.
Uitvoering met lage latentie
Een lage latentie-uitvoering wordt bereikt door infrastructuureenvoud en procesisolatie.
Het project vermijdt onnodige frameworks en zware orchestratielagen. Het handelssysteem draait als directe Python-processen met minimale middleware tussen strategielogica en uitvoering.
Belangrijke op latentie gerichte ontwerpkeuzes zijn:
Toegewijd Handelsproces
De handelsbot draait onafhankelijk van de Telegram-interface.
Dit betekent:
- •Telegram-verkeer kan de handelslogica niet bevriezen
- •Berichtvertragingen hebben geen invloed op de uitvoering
- •Externe meldingen blijven geïsoleerd
Zelfs als Telegram onbeschikbaar wordt, blijft de handelsengine werken.
Permanente TCP-communicatie
Communicatie tussen modules gebruikt een permanente TCP-laag in plaats van tijdelijke processen of trage IPC-mechanismen te starten.
Dit biedt:
- •Snelle commando-levering
- •Lichtgewicht berichtenroutering
- •Realtime logstromen
- •Communicatie met minimale overhead
Logs van de handelsengine worden via de TCP-pijplijn direct doorgestuurd naar de Telegram-bot, waardoor bijna realtime monitoring mogelijk is zonder de uitvoering te blokkeren.
Achtergrondthread Architectuur
Verschillende bewerkingen draaien onafhankelijk van de kernstrategielus:
- •Persistentie-opslagen
- •TCP-communicatie
- •Afhandeling van Telegram-commando's
- •Doorsturen van logs
- •Herstelworkers
Dit voorkomt dat trage I/O-bewerkingen de handelsuitvoering onderbreken.
Automatische Herstart Infrastructuur
De
Deze minimaliseert downtime en houdt de herstellatentie extreem laag.
In plaats van handmatige tussenkomst te vereisen, herstelt de infrastructuur services automatisch binnen enkele seconden.
Minimale Runtime Stack
Het systeem vermijdt bewust:
- •Zware webframeworks
- •Overhead van containerorkestratie
- •Databaseservers
- •Complexe berichtenbrokers
- •Grote afhankelijkheidsketens
Het resultaat is een lichtgewicht uitvoeringsomgeving die zich volledig richt op handelsprestaties en operationele stabiliteit.
De infrastructuur fungeert als een hogesnelheidsbasis waar gebruikers hun eigen handelsalgoritmen kunnen implementeren terwijl ze al professionele persistentie, logging, monitoring, herstartherstel en communicatiesystemen volledig geïntegreerd hebben.