Ich bin auf dem Rückweg von der Rust Conf. Beim Unconf hatten wir eine produktive Diskussion über das Debuggen und Benchmarking asynchroner Anwendungen. Viele interessante Erkenntnisse wurden geteilt. Ich versuche, einige davon hier aufzuzählen, zusammen mit einigen meiner eigenen Erfahrungen. Dies ist der erste Entwurf von etwas, das hoffentlich zu einem lebenden Dokument bewährter Verfahren werden kann. Zögern Sie nicht, ein Issue einzureichen oder einen PR zu öffnen. Ich hoffe, in den kommenden Tagen auch eine Beispielanwendung hinzuzufügen, die diese Probleme zusammen mit dem Aussehen des dial9 trace demonstriert.— Russell

Es gibt wenige feste und unumstößliche Regeln für das Schreiben von Code, der auf Tokio-Laufzeiten gut performt; die Antwort auf so viele Fragen lautet „es kommt darauf an“. Die Leistung einer Arbeitslast hängt davon ab, was sonst noch in diesem Moment auf der Laufzeit läuft. Deshalb treten so viele Probleme nur in der Produktion auf! Das Schreiben asynchroner Anwendungen mit guter Leistung ist ein Gleichgewicht zwischen Fairness und Batching, Konkurrenz und Isolation. Dieser Beitrag legt einige allgemeine Prinzipien dar und behandelt Ausnahmen, wo ich kann. Er setzt grundlegende Vertrautheit mit der work-stealing-Laufzeit von Tokio voraus; eine Zusammenfassung auf hoher Ebene ist im Anhang enthalten.

Allgemeine Prinzipien

Stellen Sie zunächst fest, ob Sie überhaupt ein Problem haben. Wenn Sie anfangen, in einer Tokio-Anwendung nach Warnsignalen zu suchen, werden Sie sie finden. Fast jede reale Anwendung, die ich gesehen habe, hat polls, die viel länger sind als die 10-100 Mikrosekunden, die Alice Ryhl in ihrem hervorragenden Beitrag What is Blocking? empfiehlt. Diese Probleme können die Anwendungsmetriken oder das Verhalten, das Ihnen tatsächlich wichtig ist, beeinflussen oder auch nicht. Es ist wichtig, von einer realen Metrik rückwärts zu arbeiten, die Sie verbessern möchten. Beispielsweise kann eine Anwendung lange polls haben, die völlig harmlos sind; sie zu „beheben“ wird benutzerorientierte Metriken nicht messbar beeinflussen. In der überwiegenden Mehrheit der Probleme, auf die ich gestoßen bin, lag das Problem im Anwendungscode selbst, oft in der Interaktion zwischen mehreren Komponenten eines verteilten Systems (und nicht tatsächlich in Tokio). dial9 hat Tokio viel Sichtbarkeit verliehen; mindestens genauso oft, wie es ein Tokio-Problem findet, zeigt es tatsächlich klar dessen Fehlen auf. Natürlich ist es manchmal ein Tokio-Problem. Was Tokio-Metriken betrifft, ist die nützlichste das kürzlich hinzugefügte schedule latency histogram. Schedule latency ist die Zeitspanne zwischen dem Moment, in dem Ihre Aufgabe bereit zur Ausführung ist, und dem Moment, in dem Tokio tatsächlich das future pollt. Obwohl dies Ihnen nicht sagt, was die Ursache ist, ist die scheduling latency das häufigste Symptom schlechter Interaktionen zwischen Tokio und Ihrem Code.

Für Latenz aufteilen, für Durchsatz bündeln. Häufiger yielden, um die Latenz zu optimieren. Niedrige Latenz über viele Anfragen erfordert Fairness zwischen Verbindungen. Betrachten Sie Redis (oder jede Anwendung, die Request-Pipelining unterstützt). Eine naive Implementierung liest Daten direkt von der Verbindung, solange mehr Daten verfügbar sind. Wenn Anfragen gepipelined werden, landet die gesamte gepipelinede Anfrage in einem In-Memory-Puffer. Wenn Sie Frames daraus lesen, wird jeder Poll::Ready sein, ohne zum Netzwerk zurückzukehren. Dies erzeugt sowohl lange polls als auch Unfairness zwischen Clients. Die Auswirkung auf den Durchsatz ist normalerweise geringer: Es wird die gleiche Anzahl von Anfragen verarbeitet. Die Latenz jedoch ändert sich dramatisch, weil eine ganze Pipeline hinter einer anderen warten kann. Explizites yielden nach jeder Anfrage kann die Latenz in diesem Beispiel um etwa 10× reduzieren. Sie können es noch besser machen, indem Sie nur nach mehreren aufeinanderfolgenden sofort bereiten Lesevorgängen yielden.

Wichtige Entitäten: Unternehmen: Tokio, Redis | Personen: Russell, Alice Ryhl | Orte: Rust Conf