Kernaussagen
- Die Go-Sprache ist nicht immer schnell. Im Gegenteil, eine JS-Runtime kann sogar schneller sein.
- Go steht für Einfachheit und Effizienz, kann in realen Umgebungen jedoch schwächer performen als erwartet.
- Besonders in Situationen mit viel Datenbank-I/O kann die Leistung im Vergleich zu JavaScript-Runtimes wie Bun abfallen.
Benchmark-Ergebnisse
- Go zeigte einen höheren Request-Durchsatz und einen geringeren Speicherverbrauch, allerdings war die CPU-Auslastung 2- bis 3-mal höher.
- In realen Umgebungen mit viel DB-I/O zeigte Bun (in der Kombination aus dem Elysia-Framework und der MySQL2-Bibliothek) jedoch eine stabilere und effizientere Leistung.
- Der standardmäßige HTTP-Router hatte eine niedrige Performance; nach dem Wechsel zum Fiber-Framework wurde eine ähnliche Antwortgeschwindigkeit wie mit Bun erreicht. (Verwendet nicht den Standard-HTTP-Router von Go!)
Vorteile von Go, die mir bei diesem Benchmark aufgefallen sind
- Die Bereitstellung verschiedener primitiver Typen und Typsicherheit.
- Single-Binary-Deployment: Bereitstellung als einfache ausführbare Datei, ohne Runtime-Abhängigkeiten.
- Goroutines: effiziente Unterstützung für parallele Verarbeitung; bei richtigem Einsatz lässt sich die Hardwareleistung maximieren.
Grenzen und Verbesserungspotenzial, die ich durch diesen Benchmark gespürt habe
- Vermutetes Performance-Problem beim MySQL-Treiber: Der go-mysql-driver von Go ist stabil, aber langsam und scheint leistungsmäßig hinter
mysql2 aus JavaScript zurückzubleiben. (Natürlich kann ich mich auch irren.)
- Bei Aufgaben ohne DB-Verbindungen zeigt Go die bessere Performance. Vielleicht ist das auch ganz selbstverständlich.
- Niedrige Performance des HTTP-Routers: Verwendet für eure geistige Gesundheit Fiber oder ein anderes Framework!
Warum ich Go trotz Unzufriedenheit mit der Performance weiter verwenden will
- Die Typsicherheit von Go, das Single-Binary-Deployment und die Parallelisierungsleistung von Goroutines sind für mich als Entwickler sehr attraktiv. Typen, die TypeScript nicht ersetzen kann, und die Bereitstellung einer einzelnen Binärdatei ohne
npm install waren ein wirklich großer Vorteil.
- Weil ich zusätzliches Potenzial zur Performance-Optimierung sehe, habe ich mich entschieden, Go weiter zu lernen und einzusetzen.
Worte an Entwickler
- Jede Sprache und jede Technologie hat Vor- und Nachteile. Ich denke, das gilt auch für Go.
- Statt von der Performance von Go enttäuscht zu sein, sollte man seine Stärken gut nutzen und weiter nach Mitteln suchen, die Leistungsgrenzen zu durchbrechen.
- Ich habe diesen Beitrag geschrieben, um Entwicklern, die Go verwenden, solche Analyseergebnisse als Information zu teilen.
16 Kommentare
Völlig off-topic, aber die Schriftart IBM Plex Sans KR ist echt wunderschön.
Ich mochte diese Schriftart auch wirklich sehr und habe sie verwendet, aber es gibt genau einen kleinen Wermutstropfen: Auf Monitoren mit niedriger Auflösung sieht sie auffällig weniger schön aus. Haha, auf einem 5K-Monitor sieht sie dagegen wirklich toll aus!
Ich finde, man sollte sehr vorsichtig sein, wenn man etwas kritisiert.
Es ist unklar, ob es sich um ein sprachspezifisches Problem, ein Problem einer bestimmten Bibliothek oder ein Problem im Code handelt, und in einem Zustand, in dem auch nicht genügend Informationen bereitgestellt wurden, damit andere es reproduzieren können, öffentlich zu behaupten, etwas sei schlecht,
ist selbst dann, wenn das nicht Ihre Absicht war, für die Menschen, die in diesem Ökosystem leben, wohl kein angenehmer Inhalt.
Hallo! Zunächst einmal vielen Dank, dass Sie sich die Zeit für Ihren wertvollen Kommentar genommen haben. Ich kann nachvollziehen, mit welcher Haltung Sie Ihre Meinung geäußert haben, und falls es so wirkte, als hätte ich die Zukunft der Go-Sprache oder ihre Nutzer kritisiert, dann war das nicht meine Absicht. Dafür möchte ich mich noch einmal entschuldigen. Und wenn es für Sie in Ordnung ist: Wenn Sie auf den Titel des Artikels klicken, finden Sie dort verschiedene Daten sowie zusätzlich einen Blogbeitrag einer anderen Person. Ich denke, wenn Sie das lesen (auch wenn es etwas lang ist), können Sie meine Absicht noch klarer verstehen.
Ich denke, dass eine Programmiersprache in gewisser Weise wie ein Auto ist. Jedes Auto hat verschiedene Vor- und Nachteile, die Anschaffung kostet jeweils unterschiedlich viel, und obwohl sie scheinbar die gleiche Rolle erfüllen, verfolgen sie doch unterschiedliche Werte — darin ähneln sie sich, wie ich finde. Natürlich halte ich es auch für völlig selbstverständlich, dass man ein bestimmtes Fahrzeug besonders schätzt und liebt. Ich selbst liebe mein Auto und vertraue dem Hersteller.
Trotzdem habe auch ich Punkte, die ich an meinem Auto bedaure oder über die ich unzufrieden bin, und Reviewer, die Fahrzeugmodelle regelmäßig testen, teilen ihre Einschätzungen immer, indem sie sie in vielerlei Hinsicht mit Konkurrenzmodellen vergleichen. Wenn jemand sagt, dass die Getriebeleistung meines Autos nicht besonders gut sei oder dass der Verbrauch schlecht sei, dann fühlt sich das für mich ehrlich gesagt auch nicht gut an. Trotzdem versuche ich, mich selbst als Fahrer und das Auto getrennt voneinander zu betrachten. Außerdem bemühe ich mich, über das Auto, das ich fahre, mehr zu erfahren — sowohl über seine Stärken als auch über seine Schwächen. Vielleicht fahre ich irgendwann ein anderes Auto, aber die Fahrerfahrung, die ich jetzt sammle, wird mir dann trotzdem noch helfen.
In der Kurzfassung konnte ich das nicht ausführlich erwähnen, aber im eigentlichen Blogbeitrag habe ich am Ende geschrieben, dass ich Go trotz der Punkte, die ich schade finde, weiter benutzen (= weiterfahren) möchte, weil die Vorteile immer noch größer sind. Ich versuche, möglichst viele verschiedene Sprachen (= Fahrzeuge) zu nutzen, weil jede Sprache andere Werte und Stärken verfolgt. Das ist auch der Grund, warum ich trotz einer JS-Laufzeitumgebung, die ich bisher gut genutzt habe, bewusst zu Go wechseln möchte.
Ich dachte, ich hätte den Text nach meinem Ermessen sorgfältig so geschrieben, dass möglichst keine unnötige Sprachdebatte entsteht. Wenn sich dennoch einige Gopher durch diesen Beitrag unwohl oder verärgert fühlen, hoffe ich noch einmal, dass Sie mir das nachsehen. Und damit möchte ich meinen Kommentar mit dem Hinweis beenden, dass ich ein romantischer Coder bin, der sogar die oft so sehr kritisierte Sprache PHP liebt!
Im Originaltext steht die eigene Analyse des Autors zu den langsamen Stellen sowie die Begründung, warum er trotzdem Go verwenden würde. Ich kann daher ehrlich gesagt nicht gut nachvollziehen, aus welchem Grund Sie diesen Artikel als Werturteil aufgefasst haben.
Etwas TMI, aber die
std-Bibliothek von Go verliert mit der Zeit an Performance. Der Hauptgrund ist der Trade-off durch die vielen zusätzlichen Funktionen zur Einhaltung von RFC-Standards und die zahlreichen gemeldeten Sicherheitslücken.In letzter Zeit ist außerdem zu erwarten, dass der Performance-Verlust etwas größer wird, um die FIPS-Zertifizierung zu bestehen.
All diese Hintergründe komplett auszublenden und für ein möglichst einfaches, spezifisches Szenario nur kurz hinzuschreiben, die Performance sei schlecht, reicht meiner Meinung nach völlig aus, um bei vielen Menschen Missverständnisse hervorzurufen T_T
Ich warte auf Version 1.0 von tsboard, haha.
Vielen Dank fürs Warten! Ich mache mich mit Freude an die Arbeit, haha.
Ich denke, dass JS durch die Nutzung von JIT keinen besonderen Grund hat, langsam zu sein.
Wenn man Multithreading, Stabilität usw. außen vor lässt ...
Was ich durch diesen Benchmark selbst neu entdeckt habe (?), ist, dass ich es wohl so deutlich sagen kann, weil auch die Stabilität auf einem Niveau ist, bei dem es keine größeren Probleme gibt. Dass Multithreading definitiv Orchestrierung erfordert (ich bin mir nicht sicher, ob man das so sagt), ist natürlich etwas umständlich.
Die Website ist nicht erreichbar – bin ich der Einzige?
Hallo! Vielen Dank für den Hinweis in den Kommentaren, haha. Ich konnte die Website noch nicht auf ein Hosting umziehen, daher gibt es gelegentlich Zugriffsstörungen. Ich werde das so schnell wie möglich beheben. (Im Moment arbeitet zu Hause ein Mini-PC auf Hochtouren 😂)
Oh, jetzt geht es. Ich werde es aufmerksam lesen!
Die Website wurde von einem Mini-PC im Zimmer auf einen virtuellen Server in der Größe eines Einzimmerapartments umgezogen ...! Heute mussten unerwartet viele von euch wieder gehen, nachdem ihr vorbeigeschaut hattet, aber ich kann euch nun mitteilen, dass es jetzt keine Probleme mehr gibt!
Ich bin gespannt, ob ein Experiment mit dem Treiber
github.com/jackc/pgx/v5und PostgreSQL zu einem anderen Ergebnis führen würde.Ich frage mich auch, ob dieses Ergebnis auf MySQL beschränkt ist oder ob es für alle Szenarien gilt, in denen eine DB verwendet wird. Ich denke, dass irgendwann andere ihre Ergebnisse teilen werden, haha