Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Maximieren Sie die Lambda-Leistung SnapStart

Leistungsoptimierung

Um die Vorteile von zu maximieren SnapStart, empfehlen wir, Klassen, die zur Startlatenz beitragen, in Ihrem Initialisierungscode und nicht im Funktionshandler vorab zu laden. Dadurch wird die Latenz, die mit dem starken Laden von Klassen verbunden ist, aus dem Aufrufpfad entfernt, wodurch die Startleistung mit optimiert wird. SnapStart

Wenn Sie Klassen während der Initialisierung nicht vorab laden können, empfehlen wir, dass Sie Klassen mit Dummy-Aufrufen vorab laden. Aktualisieren Sie dazu den Code des Funktionshandlers, wie im folgenden Beispiel aus der Funktion pet store im AWS GitHub Labs-Repository gezeigt.

private static SpringLambdaContainerHandler<AwsProxyRequest, AwsProxyResponse> handler;
  static {
      try {
          handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class);

          // Use the onStartup method of the handler to register the custom filter
          handler.onStartup(servletContext -> {
              FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class);
              registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*");
          });

          // Send a fake Amazon API Gateway request to the handler to load classes ahead of time
          ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity();
          identity.setApiKey("foo");
          identity.setAccountId("foo");
          identity.setAccessKey("foo");

          AwsProxyRequestContext reqCtx = new AwsProxyRequestContext();
          reqCtx.setPath("/pets");
          reqCtx.setStage("default");
          reqCtx.setAuthorizer(null);
          reqCtx.setIdentity(identity);

          AwsProxyRequest req = new AwsProxyRequest();
          req.setHttpMethod("GET");
          req.setPath("/pets");
          req.setBody("");
          req.setRequestContext(reqCtx);

          Context ctx = new TestContext();
          handler.proxy(req, ctx);


      } catch (ContainerInitializationException e) {
          // if we fail here. We re-throw the exception to force another cold start
          e.printStackTrace();
          throw new RuntimeException("Could not initialize Spring framework", e);
      }
  }

Bewährte Methoden für Netzwerke

Der Zustand der Verbindungen, die Ihre Funktion während der Initialisierungsphase erstellt, wird nicht garantiert, wenn Lambda Ihre Funktion aus einem Snapshot wieder aufnimmt. In den meisten Fällen werden Netzwerkverbindungen, die ein AWS SDK herstellt, automatisch wieder aufgenommen. Für andere Verbindungen empfehlen wir die folgenden bewährten Methoden.

Wiederherstellen von Netzwerkverbindungen

Stellen Sie Ihre Netzwerkverbindungen immer wieder her, wenn Ihre Funktion von einem Snapshot fortgesetzt wird. Wir empfehlen, dass Sie die Netzwerkverbindungen im Funktionshandler wiederherstellen. Alternativ können Sie ein afterRestore-Laufzeit-Hook verwenden.

Verwenden Sie den Hostnamen nicht als eindeutige ID der Ausführungsumgebung

Wir raten davon ab, hostname zu verwenden, um Ihre Ausführungsumgebung als eindeutigen Knoten oder Container in Ihren Anwendungen zu identifizieren. Bei SnapStart wird ein einzelner Snapshot als Ausgangsstatus für mehrere Ausführungsumgebungen verwendet, und alle Ausführungsumgebungen geben denselben hostname Wert für zurückInetAddress.getLocalHost(). Für Anwendungen, die eine eindeutige Identität oder einen eindeutigen hostname-Wert der Ausführungsumgebung erfordern, empfehlen wir, im Funktionshandler eine eindeutige ID zu generieren. Oder verwenden Sie einen afterRestore-Laufzeit-Hook, um eine eindeutige ID zu generieren, und verwenden Sie dann die eindeutige ID für die Ausführungsumgebung.

Vermeiden der Bindung von Verbindungen an feste Quellports

Wir empfehlen, Netzwerkverbindungen nicht an feste Quellports zu binden. Wenn eine Funktion nach einem Snapshot wieder aufgenommen wird, werden die Verbindungen neu aufgebaut, und Netzwerkverbindungen, die an einen festen Quellport gebunden sind, können fehlschlagen.

Vermeiden Sie die Verwendung von DNS Java-Cache

Lambda-Funktionen speichern bereits DNS Antworten im Cache. Wenn Sie einen anderen DNS Cache mit verwenden SnapStart, kann es zu Verbindungstimeouts kommen, wenn die Funktion von einem Snapshot aus wieder aufgenommen wird.

Die java.util.logging.Logger Klasse kann den Cache indirekt aktivieren. JVM DNS Um die Standardeinstellungen zu überschreiben, setzen Sie networkaddress.cache.ttl vor der Initialisierung auf 0. logger Beispiel:

public class MyHandler {
  // first set TTL property
  static{
   java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
  }
 // then instantiate logger
  var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class);
}

Um UnknownHostException Ausfälle in der Java 11-Runtime zu vermeiden, empfehlen wir, den Wert auf 0 zu setzen. networkaddress.cache.negative.ttl In Java 17 und späteren Laufzeiten ist dieser Schritt nicht erforderlich. Sie können diese Eigenschaft für eine Lambda-Funktion mit der AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0 Umgebungsvariablen festlegen.

Durch das Deaktivieren des JVM DNS Caches wird das verwaltete Caching von Lambda nicht deaktiviert. DNS