Actix (Rust) vs Fiber (Go): Performance (Latency - Throughput - Saturation - Availability)

Summary

In diesem Video werden Rust und Go anhand von realen Anwendungsfällen miteinander verglichen. Der Autor führt zwei Tests durch, bei denen Rust mit dem Actix-Framework und Go mit dem Fiber-Framework in einer AWS EKS-Umgebung auf Kubernetes getestet werden. Es werden verschiedene Metriken wie CPU-Nutzung, Speicherverbrauch und Latenz gemessen, um die Leistung beider Frameworks zu bewerten. Besonders überraschend ist das Verhalten der beiden Sprachen bei der Verarbeitung von Datei-Uploads und Datenbankinteraktionen. Der Test zeigt, dass Go in bestimmten Szenarien eine bessere Leistung bietet, insbesondere bei Latenzen und Ressourcenverbrauch.

Takeaways

• 😀 Der Vergleich von Rust und Go basiert auf realen Anwendungsfällen und nicht nur auf einfachen Algorithmen wie Fibonacci.
• 😀 Rust hat im vorherigen Test in Bezug auf Effizienz besser abgeschnitten, aber dieser Test konzentriert sich auf die Frameworks Actix (Rust) und Fiber (Go).
• 😀 Die Tests wurden auf einem Produktions-EKS-Cluster in AWS durchgeführt, um die Leistung in einer realen Umgebung zu messen.
• 😀 Die Verfügbarkeit der Anwendungen wird gemessen, indem die Anzahl der fehlgeschlagenen HTTP-Anfragen (Statuscodes über 400) im Verhältnis zur Gesamtzahl der Anfragen berechnet wird.
• 😀 Beim ersten Test, bei dem nur die Frameworks verglichen wurden, zeigte Go eine bessere Leistung in Bezug auf CPU-Nutzung und Latenz als Rust.
• 😀 Der zweite Test simuliert ein realistischeres Szenario, bei dem eine Datei hochgeladen, in einer S3-Bucket gespeichert und Metadaten in einer PostgreSQL-Datenbank abgelegt werden.
• 😀 In Bezug auf CPU-Nutzung und Latenz war Go in den meisten Fällen effizienter als Rust, insbesondere bei der Dateiübertragung und S3-Interaktionen.
• 😀 Prometheus-Metriken wurden verwendet, um die Leistung zu überwachen und zu messen, insbesondere bei der Messung der Dauer von Dateioperationen und Datenbankzugriffen.
• 😀 Bei der Nutzung von Prometheus wird empfohlen, Histogramme anstelle von Zusammenfassungen zu verwenden, um die Latenzmetriken über mehrere Replikate hinweg zu aggregieren.
• 😀 Die Tests zeigen, dass die Anwendung von nur CPU und Speicher für das Auto-Scaling unzureichend sein kann, da die Anwendungen auch auf anderen Leistungsengpässen wie S3-Latenz oder Datenbankoperationen versagen können.

Q & A

Was wird in diesem Video getestet?

In diesem Video werden Rust und Go anhand von realen Anwendungsfällen verglichen, um die Leistung und Effizienz der beiden Programmiersprachen unter Produktionsbedingungen zu bewerten. Es werden zwei Tests durchgeführt: einer, um die Leistung der Frameworks zu messen, und ein weiterer, der eine realistische Anwendungs-Szenario-Simulation mit Datei-Uploads und Datenbankoperationen enthält.

Welche Frameworks werden in diesem Vergleich verwendet?

Für Rust wird das Actix-Framework und für Go das Fiber-Framework verwendet, da beide als populäre Frameworks gelten.

Welche Art von Infrastruktur wird für die Tests verwendet?

Die Tests werden auf einem Produktions-EKS-Cluster (Amazon Elastic Kubernetes Service) in AWS durchgeführt. Dabei kommen m6a.2xlarge-Instanzen zum Einsatz.

Was ist der Unterschied in der Nutzung von CPU und Speicher zwischen Rust und Go in den Tests?

Rust benötigt zu Beginn weniger Speicher als Go, zeigt jedoch bei steigendem Lastaufkommen höhere CPU-Nutzung. Go hingegen bleibt bei CPU- und Speichernutzung effizienter, insbesondere bei höheren Client-Anzahlen.

Warum ist der Test mit Datei-Uploads und Datenbankoperationen interessant?

Dieser Test simuliert eine realistische Nutzung von Webanwendungen, bei dem Dateien auf S3 hochgeladen und Metadaten in einer PostgreSQL-Datenbank gespeichert werden. Hierbei werden die Ressourcenanforderungen und Latenzen in realen Workloads getestet, was zu überraschenden Ergebnissen führt.

Was misst die Verfügbarkeit in diesem Test und warum ist sie wichtig?

Die Verfügbarkeit wird als Verhältnis der fehlgeschlagenen HTTP-Anfragen (Statuscodes höher als 400) zur Gesamtzahl der Anfragen gemessen. Eine hohe Verfügbarkeit bedeutet, dass die Anwendung zuverlässig funktioniert und der Nutzer kaum fehlerhafte Antworten erhält.

Was sind Prometheus Summary- und Histogramm-Metriken und wie unterscheiden sie sich?

Summary-Metriken berechnen Prozentwerte auf der Client-Seite, was sie bei horizontal skalierbaren Anwendungen ungeeignet macht, da sie nicht aggregiert werden können. Histogramm-Metriken dagegen sammeln Daten in definierten Buckets, die leicht aggregiert werden können, was sie für horizontal skalierbare Anwendungen geeignet macht.

Warum ist die Wahl der richtigen Metrik für Prometheus entscheidend?

Die Wahl der richtigen Metrik ist entscheidend, da sie beeinflusst, wie genau und effizient die Leistungsdaten aggregiert und analysiert werden können, besonders bei Anwendungen, die horizontal skaliert werden. Eine falsche Wahl kann zu ungenauen Ergebnissen und schwieriger Skalierbarkeit führen.

Welche Unterschiede wurden bei der zweiten Testreihe festgestellt?

In der zweiten Testreihe, bei der eine Datei hochgeladen und in einer Datenbank gespeichert wird, zeigte sich, dass Rust mehr CPU und längere Latenzzeiten benötigt, insbesondere bei der Datei-Upload-Phase. Die Datenbankoperationen selbst waren jedoch in beiden Sprachen nahezu identisch in Bezug auf Latenz und Leistung.

Warum ist es wichtig, Prometheus und benutzerdefinierte Metriken in Kubernetes zu verwenden?

Durch die Verwendung von Prometheus und benutzerdefinierten Metriken können Anwendungen genau überwacht und skaliert werden, basierend auf den tatsächlichen Leistungsanforderungen statt nur auf CPU- und Speicherverbrauch. Dies hilft, die Skalierung und Verfügbarkeit der Anwendung zu optimieren, ohne dass es zu unnötigen Ausfällen kommt.