Aws-lambda-dotnet: C# Lambda-Leistung vs. Node vs. Python

Performance ist etwas, an dem wir mit Lambda und allen unterstützten Laufzeiten immer weiter arbeiten werden. Jede Sprache hat ihre Stärken und Schwächen, deshalb haben wir so lustige Sprachkriege :)

Dieser Test misst nur die Startzeit der Sprachlaufzeit, was dynamische Sprachen wie Node.js und Python im Vergleich zu statischen Sprachen wie C# und Java aufgrund des Fehlens von Typprüfungen und langsamerem Laden von Abhängigkeiten immer schnell waren.

Entschuldigung, ich wollte es nicht schließen. Fühlen Sie sich frei, das Gespräch fortzusetzen.

Danke, dass du das offen hältst. Es ist nicht als Kritik gedacht, sondern als Grundlage für eine offene Diskussion.

In Ihrer Antwort haben Sie erwähnt, dass der Test die Startzeit der Sprache misst. Ich hätte gerne mehr Klarheit über diese Aussage. Ich dachte beim ersten Treffer, die Anwendung wird bereitgestellt (falls erforderlich) und dann gestartet, aber bei weiteren Treffern wird sie aufgewärmt. Wenn es jedes Mal startet, hat es keinen Vorteil, einmal ausgeführten Code (zB das Lesen von Konfigurationswerten) in den Konstruktor der Handler-Klasse zu verschieben, da er sowieso bei jedem Aufruf konstruiert wird. Das habe ich aus deiner re:Invent-Präsentation jedoch nicht verstanden. Könnten Sie das klären. Vielen Dank!

Um mein Verständnis zu bestätigen, habe ich hier noch einmal gelesen, wie der Lambda-Container funktioniert: http://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction.html

@bjorg @normj die Dokumentation ist diesbezüglich ziemlich vage :(
Ich habe unten Feedback gegeben und hoffe, dass es geklärt wird

• „Wie können wir es besser machen?
  Geben Sie genau an, wo die tatsächliche Zeit für 'irgendwann' nachgeschlagen werden kann für die Aussage: 'AWS Lambda verwaltet den Container für einige Zeit in Erwartung eines weiteren Lambda-Funktionsaufrufs.'
• Was versuchst du zu machen?
  zu verstehen, wie lange es wahrscheinlich ist, dass ein Container tatsächlich wiederverwendet wird, um die Leistung vorherzusagen

@bjorg, was Sie hier gepostet haben, ist nicht die Lambda-_Kaltstartzeit_. Aber die _warme Reaktionszeit_.

Wenn eine C#-Funktion zum ersten Mal aus dem Kalten startet, kann dies bis zu ein paar hundert Millisekunden dauern (in meinem Fall sind es 500 ms). Sobald es aufgewärmt ist, bleibt es am Leben und bedient Anfragen mit einer schnelleren Geschwindigkeit, ähnlich der von Ihnen geposteten (in meinem Fall waren es etwa 0,9 bis 1 ms). Irgendwann stirbt es am Ende seiner Lebensdauer oder es kommt zu Autoscaling und mehr kalte Lambdas starten. Um die Startzeit abzurufen, warten Sie etwa 15 Minuten und klicken Sie dann auf Test.

Also ja, Sie stecken immer noch Dinge in Konstruktoren. Denn Sie erhalten nicht jedes Mal, wenn Sie auf Test klicken, ein brandneues Lambda. Aber Sie erhalten ein brandneues Lambda, wenn Sie nur einmal pro Stunde klicken.

In Bezug auf die Optimierung könnten Sie für die _Kaltstartzeit_:

1. Stellen Sie sicher, dass Sie immer Anfragen haben, 24x7, damit Ihre Lambdas immer warm sind
2. Richten Sie einen periodischen Ping auf Ihrem Lambda ein (entweder Cloudwatch-Zeitpläne oder Newrelic oder so), damit Ihre Lambdas immer warm sind.

Für die _warme Reaktionszeit_ macht eine Optimierung wirklich nicht viel Sinn:

1. die allgemein akzeptable menschliche Reaktionszeit beträgt 200 ms
2. weniger als 1 ms ist eigentlich ziemlich gut. Sie würden diesen Preis selten außerhalb von helloworld oder toUpper .
3. Wenn Sie ein API-Gateway vor Ihr Lambda stellen und HTTP-Aufrufe für die Welt bereitstellen. Der durchschnittliche zwischengespeicherte Anruf aus dem Web beträgt etwa 50 ms.
4. AWS rechnet Ihnen sowieso in 100-ms-Intervallen ab
5. 0,85 ms ist wahrscheinlich nahe an der Rohleistung eines normalen C#-Codes. Versuchen Sie, Ihre Funktion auf Ihrem Computer innerhalb einer Hauptmethode auszuführen, und sehen Sie.

Verwechseln Sie Leistung nicht mit Reaktionszeit. Nur weil Node in 20 ms antwortet, wenn Sie sequentiell manuell klicken, bedeutet das nicht, dass es sich genauso verhält, wenn 100.000 automatisierte Anfragen pro Sekunde überflutet werden und jede Sekunde zunimmt. Führen Sie einige echte Parallelitäts- und Lasttests durch. Sie werden möglicherweise feststellen, dass Multithread-Sprachen wie Java oder C# unter Last möglicherweise mehr Anfragen pro Sekunde verarbeiten. Ich habe die Lambda-Statistiken tatsächlich irgendwo gesehen: Python = schnellster Kaltstart, Java = schnellste warme Anfragen pro Sekunde, kann sie aber jetzt nicht finden.

Wie auch immer, dies sollte Ihre Frage hoffentlich beantworten.

fand die Diskussion mit dem Benchmark https://www.quora.com/Which-language-better-suits-for-AWS-Lambda

@yunspace , danke für die ausführliche Beschreibung. Mich interessiert vor allem, wie die aktuelle .NET Core-Implementierung Daten vom internen Rohaufruf an den C#-Handler Marshallt. Da der Handler in der Signatur variieren kann (sowohl nach Typ als auch nach Anzahl der Argumente), gehe ich davon aus, dass er über Reflektion aufgerufen wird. Meine Frage war also im Grunde, ob es eine Möglichkeit gibt, aufgerufen zu werden, ohne die Marshalling-Schicht zu treffen. Beispielsweise könnte eine Foo(Stream, ILambdaContext) Signatur ein vordefiniertes Handlermuster sein, das jegliche Logik zum Konvertieren der Nutzlast in eine POCO-Instanz umgeht.

Leider steht der Aufrufcode nicht zur Einsichtnahme zur Verfügung, daher weiß ich nicht, ob er weiter optimiert werden könnte. Ich würde erwarten, dass ein warmer Aufruf in der Leistung diesen anderen Laufzeiten sehr nahe kommt.

Für das Un-Marshalling von Roheingabe- JSON in POCO verwenden Lambdas standardmäßig Umgang mit Standarddatentypen

Ich verstehe was du meinst. Die meisten Serializer (einschließlich Json.Net) verwenden die langsame Reflektion. Um diese Theorie zu beweisen, könnten Sie wahrscheinlich sehen, ob Foo(Stream, ILambdaContext) Ihnen eine bessere Reaktionszeit für warme Aufrufe bietet. Und wenn ja, dann lohnt es sich wahrscheinlich, einen eigenen Kunden-Serializer für Strings und POCOs zu rollen.

Eigentlich habe ich nicht über den Datendeserializer gesprochen, sondern über die Methode, die den Lambda-Handler aufruft. Da der Lambda-Handler unterschiedliche Signaturen haben kann (sowohl hinsichtlich des Typs als auch der Anzahl der Argumente), muss die ihn aufrufende Methode auf Reflektion beruhen. AFAIK, es gibt keine Möglichkeit, den Lambda-Handler so zu schreiben, dass diese Komfortmaschinerie umgangen wird.

Ich habe kürzlich einige Tests dazu durchgeführt und festgestellt, dass der Serializer wirklich keine so große Wirkung hat. Wenn Sie fast alle beweglichen Teile entfernen und statische Daten oder nur leere Streams zurückgeben, scheint das Beste, was Sie erreichen können, etwa 0,85 ms bei einer warmen Funktion zu sein. Ich vermute, dass der Code, der die C#-Funktion aufruft, wahrscheinlich schuld ist und nur vom Lambda-Team ( @normj )

Für alle anderen Laufzeiten, einschließlich Java, können Sie bei einer warmen Funktion zwischen 0,22 - 0,30 ms erreichen. Das bedeutet im Wesentlichen, dass der Overhead für den Lambda-Aufruf für C# 3x-4x schlimmer ist.

Obwohl ich zustimme, dass dies nicht die ganze Geschichte erzählt, da C# wahrscheinlich schneller sein wird, um echte Arbeit zu leisten, verdient dieser Framework-Overhead einen Blick darauf. Ich gehe davon aus, dass einiges davon darauf zurückzuführen ist, dass es neu ist und die Leistung nicht die größte Priorität hatte. Auch Gerüche nach Überbeanspruchung von Reflexion ohne irgendeine Art von Caching könnten daran schuld sein.

Ich vermute auch, dass dies am frühen Code liegt. Ich wünschte, wir könnten sehen, wie es aussieht, damit wir bei der Optimierung helfen könnten. Alternativ wäre es auch hilfreich, einen niedrigeren Haken zum Experimentieren zu haben.

Auch ich wünschte, wir könnten helfen. Ich bin direkt am Rande und warte nur darauf, den C#-Kern auf vielfältige Weise zum Laufen zu bringen. Dies ist ein entscheidender Definitionsfaktor zwischen Azure und Amazon. Der serverlose C#-Ansatz ist weitaus besser, als mehrere EC2-Maschinen mit Windows-Updates, Leistungsprüfungen, SQL-Updates usw. warten zu müssen. Es ist fast ein Vollzeitjob, diese Umgebungen für die Kunden auf dem neuesten Stand zu halten.

Der serverlose C#-Ansatz ist kostengünstiger, weniger arbeitsintensiv, automatisch skalierbar und wiederverwendbar.

Das einzige andere offene Problem ist jetzt ein kostengünstiger skalierbarer RDC-Ansatz :-)

Ich habe diesen Thread an das Service-Team weitergegeben, damit er es sich anschauen kann. Ich pflege hauptsächlich die Clienttools wie diese Bibliotheken und die Visual Studio-Integration, daher kann ich nicht viel darüber sagen, was auf der Dienstseite passiert. Ich kann Ihnen in meiner einschränkenden Betrachtung des Dienstcodes sagen, dass die Reflexionsnutzung optimiert ist, aber es gibt immer andere Faktoren, die zu berücksichtigen sind.

@genifycom Meines

Um das klarzustellen, es stoppt nicht unsere Einführung von C# Lambda (oder LambdaSharp, wie wir es getauft haben). Es ist eher eine Quelle des Stolzes. :)

Verstehe vollkommen!

Ich bin mir nicht sicher, ob dies der richtige Ort ist, aber wir bauen derzeit ein Web-Backend in C# und haben Kaltstartzeiten von mehreren Sekunden, manchmal bis zu zehn oder sogar mehr. Nach diesem ersten Treffer ist jedoch alles in Ordnung. Ist dies für ein nicht triviales C#-Projekt noch normal oder können wir etwas tun, um dies zu reduzieren? Wir lieben es, in unserem vertrauten .NET-Ökosystem arbeiten zu können, aber das bereitet uns einige Kopfschmerzen.

Ich gehe davon aus, dass es mit den externen Paketen zu tun hat, die wir in das Projekt eingebunden haben und wie diese von Amazon beim Kaltstart behandelt werden, denn ein leeres Projekt scheint viel besser abzuschneiden. Ich hatte gehofft, jemand könnte hier etwas Licht ins Dunkel bringen.

@normj Gibt es Updates zu den Leistungsproblemen, die wir sehen?

@SpoonOfDoom Hast du den Rat gesehen, ihn alle 10 Minuten oder so zu schlagen? Das ist in .Net für immer ziemlich Standard. In den 90er Jahren machte es mein Hosting-Business am schnellsten, da ich wusste, dass es niemand anderes tat - Aber es ist heute sehr verbreitet und sogar gängige Tools wie dieses - https://www.iis.net/downloads /microsoft/application-initialization - das wird empfohlen. Lambda ändert das Kostenmodell, steht jedoch bis zu einem gewissen Grad vor den gleichen Herausforderungen, unabhängig davon, wie es entwickelt wird.

@bitshop Das machen wir derzeit. Wir rufen alle 10 Minuten einmal an, und meistens hilft es. Aber wir haben immer noch alle paar Stunden einige Spitzen, bei denen wir wieder den Kaltstart machen - es scheint, dass die AWS-Instanzen, auf denen .Net Lambdas ausgeführt wird, eine maximale Lebensdauer haben und dann unabhängig vom aktuellen Hot / Cold-Status eine neue verwendet wird? Ich bin mir nicht sicher.
Es scheint eine seltsame Entscheidung von Amazon zu sein, Entwicklern nicht die Möglichkeit zu geben, sich vollständig davor zu schützen (zumindest zu einem Preis). Klar, wir erreichen jetzt nur alle paar Stunden den Höhepunkt, aber wenn es von einem Kunden anstelle unseres Skripts getroffen wird, wird der Kunde immer noch genervt sein und unsere App als unzuverlässig und / oder langsam wahrnehmen.

@yunspace Es scheint, als würde die Lambda-Vorlagenfunktion immer noch eine Kaltstartzeit von über 2000 ms benötigen.
REPORT RequestId: d1e5f56c-0ea9-11e7-bb5d-bb039f76a793 Duration: 2120.69 ms Billed Duration: 2200 ms

@normj Habe ich was falsch gemacht?

Update: Ich habe also herausgefunden, dass die Startzeit ~800ms beträgt, wenn die Funktion eine Eingabe von string entgegennimmt, aber wenn ich tatsächlich einen anderen Typ dafür auswähle, wird es über 2000ms werden.

    // 800ms
    public string FunctionHandler(string input, ILambdaContext context)

    // 2000ms, Request being the other object type
    public string FunctionHandler(Request input, ILambdaContext context)

Ich habe Kaltstartzeiten von ~21 Sekunden in 128 MB für zwei verschiedene Lamba-Funktionen in C#, die beide SNS empfangen. Ich bekomme ungefähr die gleiche Zeit mit S3 Put Trigger vs SNS. Warm, es sind ~2 Sekunden.

Wenn ich den Speicher auf 256 M erhöhe, sehe ich, dass die Kabeljauzeiten auf etwa 10 Sekunden sinken usw.

Die Lambda-Protokolle zeigen, dass ich den Gesamtspeicher von 40 MB verwende.

Aus einer der Funktionen Gesamtlaufzeit:

128 MB kalt: REPORT Dauer: 21775,92 ms Abrechnungsdauer: 21800 ms Speichergröße: 128 MB Max. verwendeter Speicher: 35 MB

128 MB warm: REPORT Dauer: 1326,76 ms Abrechnungsdauer: 1400 ms Speichergröße: 128 MB Max. verwendeter Speicher: 37 MB

256 MB kalt: REPORT Dauer: 11159,49 ms Abrechnungsdauer: 11200 ms Speichergröße: 256 MB Max. verwendeter Speicher: 39 MB

256 MB warm: REPORT Dauer: 792,37 ms Abrechnungsdauer: 800 ms Speichergröße: 256 MB Max. verwendeter Speicher: 39 MB

384 MB kalt: REPORT Dauer: 7566,07 ms Abrechnungsdauer: 7600 ms Speichergröße: 384 MB Max. verwendeter Speicher: 43 MB

384 MB warm: REPORT Dauer: 850,59 ms Abrechnungsdauer: 900 ms Speichergröße: 384 MB Max. verwendeter Speicher: 47 MB

nur zum kichern:

1024 MB kalt: REPORT Dauer: 3309,12 ms Abrechnungsdauer: 3400 ms Speichergröße: 1024 MB Max. verwendeter Speicher: 38 MB

1024 MB warm: REPORT Dauer: 677,57 ms Abrechnungsdauer: 700 ms Speichergröße: 1024 MB Max. verwendeter Speicher: 41 MB

Das ist viel Overhead für den Kaltstart.

Im Vergleich dazu ist hier eine nodejs-Funktion, die ungefähr die Hälfte der Arbeit erledigt (ältere Version vor der Portierung auf C#), aber die gleiche Art von Arbeit (ein SNS nehmen, etwas in eine Datenbank schreiben, etwas in S3 speichern), aber dies scheint für alle zu gelten Board mit anderen Funktionen haben wir:

128 MB Cold: REPORT Dauer: 262,58 ms Abrechnungsdauer: 300 ms Speichergröße: 128 MB Max. verwendeter Speicher: 19 MB

128 MB Warm: REPORT Dauer: 134,79 ms Abrechnungsdauer: 200 ms Speichergröße: 128 MB Max. verwendeter Speicher: 19 MB

Der Prozentsatz des Overheads im kalten Zustand scheint viel vernünftiger zu sein.

Ich verwende die AWS-Tools von Visual Studio, um das Bundle hochzuladen. Der Code wird vor dem Hochladen für die Zielplattform vorkompiliert, oder? Fehlt mir etwas oder ist das normal? Die anderen hier gemeldeten Zahlen sind kleiner, aber ich kenne die Speicherzuweisung nicht.

Die Kaltstartzeit ist ein Problem beim Erstellen von Slack-Bots, da Slack nach 3.000 ms abläuft. Ich wünschte wirklich, es gäbe eine Möglichkeit, zu garantieren, dass eine Instanz immer verfügbar ist.

Ich habe ein Ticket für den technischen Support zu diesem Problem eröffnet. Wenn ich etwas Nützliches lerne, werde ich es hier teilen.

Obwohl es viele Workarounds gibt, um das Lambda über Cloudwatch-Pings usw. warm zu halten, sollte die Kaltstartzeit letztendlich etwas sein, mit dem Sie sich wohl fühlen. Kaltstarts kann man optimieren, aber nicht vermeiden. Ziemlich sicher, wenn die automatische Skalierung stattfindet, werden die neuen Lambdas auch aus dem kalten Zustand hochskaliert.

@bjorg um zu garantieren, dass eine Instanz immer verfügbar ist, wahrscheinlich besser EC2 oder ECS in Betracht ziehen

@InsidiousForce Ich bin überrascht, dass du 21er Kaltstarts @SpoonOfDoom erstellen

@yunspace Ketzerei! :)

Okay, nach langem Hin und Her mit den freundlichen technischen Support-Mitarbeitern von Amazon ist die grundlegende Erkenntnis aus dem Gespräch folgendes:
Sie können versuchen, Ihren Code zu optimieren - Dateigröße reduzieren, Bibliotheken wegwerfen, die nicht unbedingt erforderlich sind, versuchen, so wenig statische und andere Dinge wie möglich zu haben, die beim Start initialisiert werden, und natürlich den zugewiesenen Speicher erhöhen, um die CPU-Leistung zu erhöhen, wie besprochen in diesem Thread. Wenn Sie das Lambda durch regelmäßiges Aufrufen am Leben erhalten, kann das Problem zwar ausgedehnt, aber nicht beseitigt werden. Ein Intervall von 4 Minuten scheint in den meisten Fällen der beste Wert zu sein, aber anscheinend ist das zugrunde liegende Verhalten nicht vollständig deterministisch, daher ist es keine zuverlässige Regel. Und selbst dann wird das Problem nicht vollständig beseitigt.

Unterm Strich kommt man leider nur so weit, und irgendwann ist die Zuweisung von mehr Speicher nicht mehr machbar. Sie werden immer diese Kaltstartzeiten haben, und obwohl Sie sie möglicherweise reduzieren können, werden Sie sie wahrscheinlich nicht auf einen Punkt reduzieren können, an dem es für eine öffentlich zugängliche API oder ähnliches angemessen ist - es scheint, dass, wenn Sie Sie können es sich nicht leisten, nur ab und zu warten, dann ist C# Lambda nichts für Sie, und Sie sind mit einer EC2-Instance oder vielleicht (wie wir es jetzt) ​​Elastic Beanstalk besser dran, wenn Sie eine einfache Bereitstellung und automatische Skalierung wünschen .
Wir konvertieren jetzt unsere Lambdas in ein ASP.NET-Web-API-Projekt, das es uns ermöglicht, weiterhin eine komfortable Bereitstellung aus Visual Studio durchzuführen und einige automatische Skalierungsoptionen beizubehalten.

TL;DR: Es scheint keinen zuverlässigen Weg zu geben, dieses Problem zu umgehen. Verwenden Sie stattdessen EBS oder EC2.

Schließung wegen mangelnder Aktivität. Auch dieses Repository dient hauptsächlich der Unterstützung der Clientbibliotheken und -tools. Ein besserer Ort für diese Diskussion sind die Lambda-Foren, in denen das Lambda-Serviceteam überwacht.

Hallo an alle!
Ich habe einen Artikel erstellt, in dem ich Python vs PHP vs Java vs Ruby vs C# vergleiche.
Können Sie es überprüfen und Ihre Meinung dazu sagen? (Dies ist kein rein technisches Material, sondern eher verallgemeinernd für Anfänger)
https://www.cleveroad.com/blog/python-vs-other-programming-languages

Dieser Artikel war für mich nicht hilfreich.

Erstens war es kein Vergleich. Der Titel auf der Seite sagt "VORTEILE DER VERWENDUNG VON PYTHON GEGENÜBER ANDEREN SPRACHEN", also ist es eindeutig KEIN Vergleich.

Zweitens GIBT ES KEINE SPRACHE, DIE FÜR ALLE ANFORDERUNGEN PASST!

So ist es beispielsweise unglaublich schwierig, komplexe Frameworks mit einer Skriptsprache zu erstellen. Ihr Punkt zu Python wie in "Wir können sagen, dass Python eine minimalistische Sprache ist. Sie ist sehr einfach zu schreiben und zu lesen. Und wenn es an der Zeit ist, über ein Problem nachzudenken, kann sich ein Entwickler auf das Problem konzentrieren, nicht auf die Sprache und seine Syntax." hilft nicht einmal bei reichhaltigen Modellen und Interaktionen zwischen Modellkomponenten.

Obwohl wir anscheinend zu der Annahme verfallen sind, dass Mikrodienste alles beantworten werden, bin ich lange genug in diesem Spiel, um zu wissen, dass dies ein sehr naiver Ansatz ist.

Probleme treten in VIELEN Formen auf.

Ich stimme Genifycom zu. Darüber hinaus gibt es einige Punkte, die zweifelhaft, wenn nicht sogar falsch erscheinen. Zum Beispiel sagen , dass Sie keine Netzwerk-Basis - Anwendungen tun (ich , dass Mittel annehmen Distributed Computing?) In Python scheint nicht informiert , und die besagt , dass C # nicht über viele Bibliotheken ist eine seltsame Aussage angesichts gibt es etwa 100k Pakete allein auf Nuget .
Außerdem hat Python nicht "eine Möglichkeit, ein Problem zu lösen" - es gibt immer mehrere Möglichkeiten, Probleme zu lösen, und das hat normalerweise überhaupt nichts mit der Sprache zu tun.
Dann gibt es eine Stelle, wo Sie sich zu widersprechen scheinen, wo Sie in Ihrem Diagramm sagen, dass Python keine plattformübergreifenden Apps kann (hä? Das scheint falsch) und dann im Text "Python ist mit fast allen modernen Betriebssystemen kompatibel" .
Es gibt auch andere kleinere Probleme - zum Beispiel können Sie theoretisch in C# mit Notepad programmieren und über die Befehlszeile kompilieren, ohne dass eine IDE erforderlich ist, während eine richtige IDE wie IntelliJ auch die Python-Entwicklung erheblich erleichtert.

Darüber hinaus bin ich mir nicht sicher, ob eine GitHub-Ausgabe mit fast einem Jahr Inaktivität der richtige Weg ist, um für Ihr Blog zu werben.

genifycom und SpoonOfDoom Vielen Dank für Ihre Meinung, ich werde dies berücksichtigen.

Hier ist eine andere Meinung, die .Net Core günstiger ist:
https://read.acloud.guru/comparing-aws-lambda-performance-of-node-js-python-java-c-and-go-29c1163c2581

Irgendwelche Tipps, wie man c#-Code aus der .NET-Perspektive für Lambda-Handler effizienter macht?
Einige der Beispielfragen, die ich zu beantworten versuche:
1) Wird die statische Verwendung von Lambda-Funktionen die Wiederverwendung des Lambda-Kontexts erhöhen und die Leistung verbessern?
2) Wenn ich die Singleton-Klasse der Functions-Klasse (die alle Lambda-Handler hat) erstelle, wird die Leistung verbessert?
3) Wenn ich konstante/schreibgeschützte Variablen erstelle und sie über Lambda-Funktionen teile, wird die Leistung verbessert?

Wenn jemand Informationen hat, bitte vorschlagen

@niraj-bpsoftware warum probierst du es aus und postest deine Ergebnisse hier? Es würde mich sehr interessieren, ob es einen spürbaren Unterschied gibt. Um ehrlich zu sein, wäre ich ziemlich überrascht, wenn einer davon einen Einfluss hätte.

1) Der Vorteil des Verzichts auf eine Instanziierung, bei der es sich um einmalige Fixkosten über die Lebensdauer der Funktion handelt, scheint absolut minimal und weit über jede messbare Schwelle zu liegen.

2) Ich kann dazu nicht sprechen, da ich es nicht tue. Wenn Ihre Handler jedoch unterschiedliche Lambda-Funktionen sind, haben sie zunächst nichts gemeinsam, da sie nach meinem Verständnis alle in separaten Prozessen/Containern ausgeführt werden.

3) Dito.