Welchen Warp- und Snap-Server von Yesod sollte ich für einen Hochleistungs-Anwendungsserver wählen?

Question

Ich habe Benchmarks auf Yesods Homepage gesehen, aber sie sind meistens für statische Dateien. Und die Benchmarks auf der Snap-Website sind veraltet.

Ich versuche, ein Haskell-Modul als Service verfügbar zu machen. Die Logik des Servers besteht darin, den Funktionsnamen und die Argumente in json zu erhalten, die Haskell-Funktion aufzurufen und die Ausgabe erneut als json zu liefern. Die referenzielle Transparenz garantiert Threadsicherheit und die Fähigkeit, Funktionen zu memoisieren und zu cachen.

Wenn ich gleichzeitige Verbindungen in der Größenordnung von 2k - 5k unterstützen würde, wie würde ich dann die Implementierung durchführen? Wie skalierbar kann dieser Ansatz sein?

Answer 1

Ich würde sehr empfehlen, die Wahl zwischen Warp/Yesod und Snap abhängig davon, welches System Ihnen die besten Werkzeuge zur Erstellung Ihrer Anwendung bietet. Sowohl Warp als auch Snap verwenden denselben zugrunde liegenden GHC I/O-Manager, und beide sind hochgradig optimiert. Ich würde mich wundern, wenn eine gut geschriebene Anwendung für jedes System, die etwas nicht-triviales tut, eine Signifikanzleistungslücke zeigte.

Ihr letzter Absatz ist ein bisschen vage, aber ich denke, die grundlegende Antwort für Warp oder Snap ist, nur Ihren Code zu schreiben, und der I/O-Manager wird so gut wie möglich skalieren. Wenn Sie tatsächlich feststellen, dass gleichzeitige Verbindungen der Engpass sind, können Sie die Prefork-Technik ausprobieren, indem Sie GHC 7.8 (noch nicht veröffentlicht, aber mit einem stark verbesserten I/O-Manager) verwenden oder mehrere Server verwenden.

Answer 2

Die meisten der für Warp und Snap veröffentlichten Benchmarks basieren auf einem extrem einfachen und sehr raffinierten Benchmark, der eine statische Zeichenfolge von "pong" zurückgibt. Dies ist ideal, um zu vergleichen, wie effizient ein Webserver HTTP-Anfragen analysiert, HTTP-Antworten erstellt, usw., aber in den meisten Anwendungen ist die Zeit, die damit verbracht wird, vernachlässigbar. Zweitens, meine Vermutung ist, dass Leistungsunterschiede zwischen Warp und Snap in Zukunft wahrscheinlich abnehmen werden, da beide Server sich weiter verbessern und sich dem theoretischen Limit nähern. Außerdem erwarte ich, dass beide Server auch erheblich von den Leistungsverbesserungen in GHC 7.8 profitieren werden.

Haskell ist eine ausgezeichnete Wahl für hohe Leistung mit einer großen Anzahl von gleichzeitigen Verbindungen. Haskell hat grüne Fäden, die im Vergleich zu Fäden in den meisten anderen Sprachen extrem billig sind. Dies gibt Haskell Web-Frameworks einen großen Vorteil. Wir können für jede Verbindung einen neuen Thread erstellen und die enorme Menge an Aufwand nutzen, die in die Optimierung von GHC investiert wurde, um eine hervorragende Leistung zu erzielen und gleichzeitig ein gutes Programmiermodell beizubehalten.

In Bezug auf Yesod vs Snap gibt es einen Grund, dass die beiden als separate Projekte existieren. Sie nähern sich dem Problem der Webentwicklung in Haskell aus zwei ganz verschiedenen Richtungen. Sie profitieren beide von der Leistung, die Ihnen Haskell bietet, also sollten Sie zwischen ihnen wählen, je nachdem, welchen Ansatz Sie bevorzugen. Hier sind einige Ressourcen zum Einstieg:

• A StackOverflow question with some pretty good answers
• My very generalized comparison matrix
• A more detailed and objective comparison I wrote
• Haskell wiki page comparing web frameworks