Maximice el rendimiento de Lambda SnapStart

Ajuste del rendimiento

Para maximizar las ventajas de SnapStart, le recomendamos que precargue las clases que contribuyen a la latencia de inicio en el código de inicialización en lugar de hacerlo en el controlador de funciones. Esto elimina de la ruta de invocación la latencia asociada a la carga pesada de clases, lo que optimiza el rendimiento de inicio con SnapStart.

Si no puede precargar las clases durante la inicialización, le recomendamos que las precargue con invocaciones ficticias. Para ello, actualice el código del controlador de funciones, como se muestra en el siguiente ejemplo de la función tienda de mascotas del repositorio de Labs GitHub de AWS.

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);
      }
  }

Prácticas recomendadas para redes

El estado de las conexiones que establece la función durante la fase de inicialización no está garantizado cuando Lambda vuelve a activar la función a partir de una instantánea. En la mayoría de los casos, las conexiones de red que establece un SDK de AWS se reanudan automáticamente. Recomendamos que siga las siguientes prácticas recomendadas para otras conexiones.

Restablezca las conexiones de red.

Restablezca siempre las conexiones de red cuando la función se reanude a partir de una instantánea. Se recomienda restablecer las conexiones de red en el controlador de funciones. Como alternativa, puede utilizar un enlace de tiempo de ejecución de afterRestore.

No utilice el nombre de host como identificador único del entorno de ejecución.

Se recomienda no utilizar un hostname para identificar el entorno de ejecución como un nodo o contenedor único en las aplicaciones. Con SnapStart, se utiliza una sola instantánea como estado inicial para varios entornos de ejecución y todos los entornos de ejecución devuelven el mismo valor de hostname para InetAddress.getLocalHost(). Para las aplicaciones que requieren una identidad de entorno de ejecución o un valor de hostname único, se recomienda generar un ID único en el controlador de funciones. O bien, utilice un enlace de tiempo de ejecución de afterRestore para generar un ID único y, a continuación, utilice el ID único como identificador del entorno de ejecución.

Evite vincular conexiones a puertos de origen fijos.

Se recomienda evitar vincular las conexiones de red a puertos de origen fijos. Las conexiones se restablecen cuando se reanuda una función a partir de una instantánea y las conexiones de red que están enlazadas a un puerto de origen fijo pueden fallar.

Evite utilizar la caché de DNS de Java.

Las funciones de Lambda ya almacenan en caché las respuestas de DNS. Si utiliza otra caché de DNS con SnapStart, es posible que se agoten los tiempos de espera de conexión cuando la función se reanude a partir de una instantánea.

La clase java.util.logging.Logger puede habilitar indirectamente la caché de DNS de la JVM. Para anular la configuración predeterminada, defina networkaddress.cache.ttl en 0 antes de inicializar logger. Ejemplo:

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);
}

Para evitar errores UnknownHostException en el tiempo de ejecución de Java 11, se recomienda establecer el valor networkaddress.cache.negative.ttl en 0. En Java 17 y tiempos de ejecución posteriores, este paso no es necesario. Puede establecer esta propiedad para una función de Lambda con la variable de entorno AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0.

Al deshabilitar la caché de DNS de la JVM, no se deshabilita la caché de DNS administrada de Lambda.