Performances de la plateforme de trading avec un exemple simple


Dans cet article, je veux parler sous une forme scientifique populaire de l'optimisation du temps de réponse dans les plateformes de négociation des bourses et des banques (HFT). Pour référence, nous parlons de temps allant de centaines de nanosecondes à des centaines de microsecondes. Pour la plupart des autres applications, bon nombre des méthodes d'optimisation ci-dessous ne sont pas pertinentes simplement parce qu'il n'y a pas d'exigences aussi strictes.


Nous considérons généralement les performances en unités de bande passante. Par exemple dans Gigaflops. Dans de tels cas, la tâche d'optimisation se réduit à effectuer le nombre maximal de calculs par unité de temps ou à résoudre le problème en un minimum de temps. La conception du processeur est conçue principalement pour atteindre le nombre maximal de calculs par unité de temps et des techniques d'optimisation standard pour celui-ci.


Cependant, il existe des applications où le temps de réponse est plus important, par exemple, les plates-formes de négociation dans le commerce informatique (HFT), les moteurs de recherche, la robotique et les télécommunications. Le temps de réponse est le temps d'exécution d'une opération «unique» de ce type, par exemple, de la réception d'un package avec les devis actuels de l'échange à l'envoi de la commande de l'opération d'échange. En fait, le temps de réponse et le débit (le nombre d'opérations de ce type par unité de temps) sont étroitement liés, mais la différence est fondamentale. Il est souvent possible d'augmenter le débit simplement en ajoutant du matériel (plus de serveurs), mais l'amélioration du temps de réponse de cette manière est problématique (sauf en cas de charges de pointe).


Plusieurs excellentes techniques sont utilisées pour optimiser le temps de réponse. Certains améliorent à la fois le temps de réponse et le débit, d'autres améliorent l'un au détriment de l'autre. Par exemple, pour améliorer le débit, la mise en mémoire tampon est typique pour traiter un tableau de paquets à la fois. De toute évidence, pour le temps de réponse à un seul paquet, cette approche est nuisible.


Dans les plateformes de trading, la stabilité du temps de réponse est également très importante. La plupart des gains et pertes se produisent lors de mouvements brusques des marchés, accompagnés d'une activité anormalement élevée. La plate-forme doit supporter de telles charges. Tout bouchon peut provoquer des pertes tangibles.


En général, une telle optimisation du temps de réponse de bas niveau est un sujet complexe qui nécessite une bonne compréhension de la pile réseau, du cœur du système d'exploitation, des performances du processeur et de la plate-forme, et une synchronisation efficace des threads. Ma tâche est d'expliquer toutes ces choses complexes avec un exemple simple et compréhensible.


Travail de bureau


Utilisons l'analogie suivante. Imaginez un groupe de personnes travaillant dans un bureau. Les communications se font par l'échange de messages sur papier (lettres). Chaque lettre contient le destinataire, l'expéditeur et la tâche. Des lettres sont placées sur certaines tables du bureau. Il y a des employés qui ont pour tâche de recevoir des lettres du monde extérieur et de les mettre sur des tables. D'autres ramassent des lettres sur les tables et les transmettent aux décideurs. Chaque décideur ne travaille qu'avec un certain type de lettres (ou tâches).


Le décideur lit les lettres qui lui sont destinées et décide si cette tâche sera achevée, reportée ou ignorée. Les tâches d'exécution sont empilées sur une table distincte. Des ouvriers spéciaux ramassent des lettres de cette table et les distribuent aux artistes. Certaines lettres doivent recevoir une réponse à l'extérieur du bureau, par exemple, envoyer une confirmation à l'expéditeur externe.


Pour être plus proche de la réalité, compliquons un peu plus les conditions. Par exemple, un bureau est un réseau complexe de chambres et de couloirs, et différents types de travailleurs ne peuvent se rendre que dans certains endroits auxquels ils ont accès. Comme le disent les mathématiciens, sans perte de généralité, supposons que notre bureau, dans des conditions normales, traite 200 messages par jour avec un temps moyen de traitement des messages de 5 minutes.


Notre tâche consiste donc à minimiser le temps de traitement des messages. Dans ce cas, il est souhaitable que le temps de traitement maximal ne dépasse pas la moyenne plus de, disons, deux fois. C'est-à-dire que les sursauts d'activité doivent être gérés efficacement.


Alors par où commencer? La façon la plus simple d'embaucher plus d'employés est de traiter plus de messages. Il est agréable de rechercher des travailleurs rapides, le temps de traitement sera alors réduit. Disons que nous avons engagé Usain Bolt et les autres finalistes olympiques. Peut-être que le temps de traitement est passé à 2 minutes. Mais il est évident qu'il n'y a nulle part où aller plus loin dans cette direction. Personne ne court plus vite. La limite est atteinte. En comparant ces approches avec un ordinateur, l'embauche de personnes consiste à acheter du matériel supplémentaire (serveurs, processeurs, cœurs) pour augmenter le nombre de threads d'exécution. L'embauche d'athlètes est similaire à l'achat du fer le plus rapide (fréquence maximale en premier lieu).


La disposition de notre bureau n'est peut-être pas optimale. Un espace suffisant doit être prévu pour que les travailleurs puissent travailler efficacement. Peut-être élargir les couloirs, sinon les gens doivent céder la place les uns aux autres, perdre un temps précieux? Développons. Augmentons également légèrement les pièces pour que les gens ne se pressent pas à l'approche des tables. C'est comme acheter un serveur avec plus de cœurs et plus de mémoire et de bande passante d'E / S.


De plus, nous pouvons passer au service express au lieu du courrier ordinaire pour échanger des messages avec le monde extérieur. En termes informatiques, cela revient à sélectionner et à optimiser l'équipement réseau et la pile réseau du système d'exploitation. Tout cela est un coût supplémentaire, mais nous supposons qu'ils seront certainement rentables.


Ainsi, après les innovations, notre temps de traitement des messages est tombé à, disons, une minute. Les travailleurs peuvent également être formés pour améliorer le processus de communication et d'exécution. Cela donnera peut-être 15 pour cent avec la bonne motivation. Il sait que nous avons atteint 51 secondes. Ceci est similaire à l'optimisation logicielle.


La prochaine étape est d'essayer d'éviter les collisions entre nos travailleurs en mouvement rapide. Le goulot d'étranglement probable est l'approche des tables. Il est conseillé aux travailleurs d'avoir un accès instantané et simultané aux bureaux dont ils ont besoin. Vous pouvez trier les messages sur les tableaux lors de la mise en page (placés dans des dossiers séparés) pour accélérer l'accès. Les messages peuvent également avoir des priorités différentes. Dans le programme, il s'agit d'un analogue de la synchronisation des threads. Les flux doivent avoir un accès parallèle et maximal illimité aux données. La résolution des problèmes de synchronisation des threads entraîne souvent une augmentation considérable du débit du système et contribue à améliorer les temps de réponse. Dans le sens du traitement des salves d'activité, l'influence d'un algorithme de synchronisation optimal est généralement difficile à surestimer.


De plus, les travailleurs peuvent parfois se retrouver devant une porte fermée. D'autres problèmes mineurs de cette nature peuvent entraîner des inconvénients et des retards. Il est conseillé de remplir les conditions suivantes: le nombre de personnes dans un bâtiment donné ne dépasse jamais sa capacité, la vitesse des travailleurs est illimitée, aucune action n'est prise sans rapport avec le travail principal et aucun étranger ne se lance dans le processus de travail. En termes informatiques, cela signifie que le nombre de threads ne dépasse jamais le nombre de cœurs disponibles, la plate-forme est configurée pour une fréquence / performance maximale, les modes économiques sont désactivés, le mode Turbo est activé et le noyau du système d'exploitation et d'autres applications est isolé et (presque) n'affecte pas la plate-forme de négociation.


Il est maintenant temps d'examiner encore plus attentivement les conditions dans le bureau. Les portes s'ouvrent-elles facilement? Le sol glisse-t-il? Cela revient à analyser les interactions avec le système d'exploitation. S'il n'y a rien à améliorer, vous pouvez essayer d'éviter l'utilisation de certaines pièces. Par exemple, au lieu de livrer des lettres par le bureau, pourquoi ne pas les jeter de fenêtre en fenêtre? Vous dites mal à l'aise? Cela peut être inconfortable, mais rapide. Ceci est similaire à l'utilisation de l'approche de contournement du noyau dans la pile réseau.


Au lieu d'utiliser la pile réseau du système d'exploitation, le contournement du noyau exécute la pile réseau dans l'espace utilisateur. Cela permet de se débarrasser de la copie inutile de données entre le système et la pile d'utilisateurs et du retard dans l'exécution du flux de réception de messages. Dans le contournement du noyau, le flux de réception attend généralement activement. Il ne s'assoit pas sur le verrou du système d'exploitation, mais vérifie en permanence la variable de verrouillage jusqu'à ce qu'il lui donne la permission de s'exécuter.


En fait, si nous avons commencé à lancer des messages à travers les fenêtres, faisons-le efficacement. L'option la plus fiable est de passer d'une fenêtre à l'autre. Ce principe est utilisé dans le protocole TCP. Ce n'est pas l'option la plus rapide. UDP vous permet de simplement déposer un message sans accusé de réception. C'est plus rapide. Personne n'est obligé d'attendre. Vous pensez que c'est la limite? Non, vous pouvez toujours apprendre à lancer à travers la fenêtre afin que la lettre tombe directement sur la table souhaitée et dans le dossier souhaité. Cette approche est appelée accès direct à distance à la mémoire (RDMA). Je pense que nous avons réduit le temps de traitement de quelques secondes à 35.


Ou peut-être construire un bureau à partir de zéro au lieu d'adapter le bureau existant à nos besoins? Tels que fournit des conditions de travail idéales. Cela améliorera peut-être le temps de réponse de quelques secondes à 20, voire moins. La conception de son propre bureau consiste à utiliser un réseau de portes programmables sur site (FPGA). Le FPGA est quelque chose comme un processeur dont le matériel est programmé pour résoudre un problème spécifique. Un processeur normal est codé pour exécuter un ensemble spécifique d'instructions sur certains types de données et le thread d'exécution (à ne pas confondre avec le thread d'application) est également corrigé. Contrairement au processeur, les FPGA ne sont pas préprogrammés pour un ensemble d'instructions, de types de données et de flux d'exécution. Ils sont programmés pour une tâche spécifique et dans cet état sont capables de l'exécuter uniquement (jusqu'à une reprogrammation ultérieure). Une programmation FPGA efficace n'est pas une tâche facile. Apporter des modifications au programme peut également nécessiter beaucoup d'efforts. Et bien que le FPGA n'implique pas l'embauche d'Usain Bolt (les fréquences sont bien inférieures à celles du processeur), mais le parallélisme illimité de l'exécution des instructions permet d'obtenir des temps de traitement des messages inférieurs à ceux du processeur.


Eh bien, en conclusion, je recommanderai des outils d'analyse de performance pour les logiciels. L'amplificateur Intel VTuneTM et la technologie Intel Processor Trace vous aident à voir en détail où et pourquoi le temps CPU est perdu.


Si le sujet vous intéresse, vous pouvez lire mes articles sur Intel Developer Zone (en anglais), qui fournissent également des conseils techniques pratiques sur l'optimisation du temps de réponse.


  • https://software.intel.com/en-us/articles/optimizing-computer-applications-for-latency-part-1-configuring-the-hardware
  • https://software.intel.com/en-us/articles/optimizing-computer-applications-for-latency-part-2-tuning-applications

Source: https://habr.com/ru/post/fr437626/


All Articles