Sugerencias

En este documento, se describen las prácticas recomendadas para diseñar, implementar y probar funciones de Cloud Functions.

Precisión

En esta sección, se describen las prácticas recomendadas generales para diseñar e implementar Cloud Functions.

Escribe funciones idempotentes

Tus funciones deben producir el mismo resultado, incluso si se llaman varias veces. Esto te permite volver a intentar una invocación si la anterior falla a mitad de camino en el código. Para obtener más información, consulta Reintenta las funciones en segundo plano.

Asegúrate de que las funciones de HTTP envíen una respuesta HTTP

Si tu función se activa con HTTP, recuerda que debes enviar una respuesta HTTP como se muestra más abajo. No hacerlo puede dar como resultado que la función se ejecute hasta el tiempo de espera. Si esto ocurre, se te cobrará por todo el tiempo de espera. Los tiempos de espera también pueden generar un comportamiento impredecible o inicios en frío en invocaciones posteriores, lo que dará como resultado un comportamiento impredecible o una latencia adicional.

Node.js

const escapeHtml = require('escape-html');

/**
 * HTTP Cloud Function.
 *
 * @param {Object} req Cloud Function request context.
 *                     More info: https://expressjs.com/en/api.html#req
 * @param {Object} res Cloud Function response context.
 *                     More info: https://expressjs.com/en/api.html#res
 */
exports.helloHttp = (req, res) => {
  res.send(`Hello ${escapeHtml(req.query.name || req.body.name || 'World')}!`);
};

Python

from flask import escape

def hello_http(request):
    """HTTP Cloud Function.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """
    request_json = request.get_json(silent=True)
    request_args = request.args

    if request_json and 'name' in request_json:
        name = request_json['name']
    elif request_args and 'name' in request_args:
        name = request_args['name']
    else:
        name = 'World'
    return 'Hello {}!'.format(escape(name))

Go


// Package helloworld provides a set of Cloud Functions samples.
package helloworld

import (
	"encoding/json"
	"fmt"
	"html"
	"net/http"
)

// HelloHTTP is an HTTP Cloud Function with a request parameter.
func HelloHTTP(w http.ResponseWriter, r *http.Request) {
	var d struct {
		Name string `json:"name"`
	}
	if err := json.NewDecoder(r.Body).Decode(&d); err != nil {
		fmt.Fprint(w, "Hello, World!")
		return
	}
	if d.Name == "" {
		fmt.Fprint(w, "Hello, World!")
		return
	}
	fmt.Fprintf(w, "Hello, %s!", html.EscapeString(d.Name))
}

No inicies actividades en segundo plano

Las actividades en segundo plano son todas las acciones que ocurren después de que finaliza la ejecución de tu función. La invocación de una función termina cuando esta muestra o indica que se completó su ejecución, por ejemplo, si llama al argumento callback en las funciones en segundo plano de Node.js. El código que se ejecute después de esto no podrá acceder a la CPU y no llevará a cabo ningún progreso.

Además, cuando se ejecutan las invocaciones siguientes en el mismo entorno, se reanuda tu actividad en segundo plano, lo que provoca interferencias en la invocación nueva. Es posible que se generen errores y comportamientos inesperados difíciles de diagnosticar. Acceder a una red después de que una función termina suele generar el restablecimiento de las conexiones (código de error ECONNRESET).

A menudo, la actividad en segundo plano se puede detectar en los registros de las invocaciones individuales, ya que aparece en las líneas posteriores a la que indica que la invocación finalizó. En otras ocasiones, este tipo de actividad puede estar mucho más oculta en el código, especialmente cuando existen operaciones asíncronas, como devoluciones de llamadas o cronómetros. Revisa tu código para asegurarte de que todas las operaciones asíncronas finalicen antes de que termines la función.

Borra los archivos temporales siempre

El almacenamiento en el directorio temporal del disco local es un sistema de archivos en la memoria. Los archivos que escribes consumen memoria disponible en tu función y, a veces, persisten entre invocaciones. No borrar estos archivos explícitamente podría generar un error por falta de memoria y un posterior inicio en frío.

Para ver la memoria que usa una función individual, selecciónala en la lista de funciones de GCP Console y elige el trazado Uso de memoria.

No intentes escribir fuera del directorio temporal y asegúrate de usar métodos independientes de SO/plataforma para construir rutas de acceso.

Puedes usar la canalización para evitar las restricciones de tamaño en archivos temporales. Por ejemplo, para procesar un archivo en Cloud Storage, puedes crear un flujo de lectura, pasarlo por un proceso basado en flujos y escribir el flujo de salida directamente en Cloud Storage.

Herramientas

En esta sección, se proporcionan lineamientos sobre cómo usar herramientas para implementar, probar y también interactuar con Cloud Functions.

Desarrollo local

La implementación de funciones tarda un momento, por lo que suele ser más rápido probar el código de la función de manera local.

Informa errores

En lenguajes que usan el manejo de excepciones, no arrojes excepciones no detectadas, ya que fuerzan los inicios en frío en las invocaciones futuras. Consulta la guía de registro de errores para obtener información sobre cómo informar errores de forma correcta.

Usa Sendgrid para enviar correos electrónicos

Cloud Functions no permite conexiones salientes en el puerto 25, por lo que no puedes establecer conexiones no seguras a un servidor SMTP. Para enviar correos electrónicos, se recomienda usar SendGrid. Puedes ver un ejemplo completo en el instructivo de SendGrid. Además, en el documento de Google Compute Engine sobre cómo enviar correos electrónicos desde una instancia, se describen otras opciones para enviar correos electrónicos.

Rendimiento

En esta sección, se describen las prácticas recomendadas para optimizar el rendimiento.

Usa las dependencias de manera inteligente

Debido a que las funciones no tienen estado, el entorno de ejecución suele inicializarse desde cero (durante lo que se conoce como inicio en frío). Cuando se genera un inicio en frío, se evalúa el contexto global de la función.

Si tus funciones importan módulos, el tiempo de carga de estos se agrega a la latencia de invocación durante un inicio en frío. Para reducir esta latencia y el tiempo que se requiere para implementar tu función, carga las dependencias correctamente y no cargues las dependencias que tu función no utiliza.

Usa variables globales para volver a usar objetos en invocaciones futuras

No se garantiza que el estado de una función de Cloud Functions se conserve para las invocaciones futuras. Sin embargo, Cloud Functions suele reciclar el entorno de ejecución de una invocación previa. Si declaras una variable en alcance global, su valor se puede volver a usar en invocaciones posteriores sin tener que volver a procesarse.

De esta manera, puedes almacenar objetos en la caché, ya que volver a crearlos en cada invocación de la función puede ser costoso. Mover estos objetos desde el cuerpo de la función al alcance global puede generar importantes mejoras en el rendimiento. En el siguiente ejemplo, se crea un objeto pesado solo una vez por instancia de la función y se comparte en todas las invocaciones de la función que alcanzan la instancia determinada:

Node.js

// Global (instance-wide) scope
// This computation runs at instance cold-start
const instanceVar = heavyComputation();

/**
 * HTTP function that declares a variable.
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
exports.scopeDemo = (req, res) => {
  // Per-function scope
  // This computation runs every time this function is called
  const functionVar = lightComputation();

  res.send(`Per instance: ${instanceVar}, per function: ${functionVar}`);
};

Python

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

def scope_demo(request):
    """
    HTTP Cloud Function that declares a variable.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """

    # Per-function scope
    # This computation runs every time this function is called
    function_var = light_computation()
    return 'Instance: {}; function: {}'.format(instance_var, function_var)

Go


// h is in the global (instance-wide) scope.
var h string

// init runs during package initialization. So, this will only run during an
// an instance's cold start.
func init() {
	h = heavyComputation()
}

// ScopeDemo is an example of using globally and locally
// scoped variables in a function.
func ScopeDemo(w http.ResponseWriter, r *http.Request) {
	l := lightComputation()
	fmt.Fprintf(w, "Global: %q, Local: %q", h, l)
}

Es muy importante almacenar en caché las conexiones de red, las referencias de la biblioteca y los objetos de cliente de la API en alcance global. Consulta Cómo optimizar las herramientas de redes para ver ejemplos.

Haz una inicialización diferida de las variables globales

Si inicializas variables en alcance global, el código de inicialización se ejecutará siempre a través de una invocación de inicio en frío, lo que aumenta la latencia de tu función. Si algunos objetos no se usan en todas las rutas de acceso del código, te recomendamos inicializarlos de forma diferida a pedido:

Node.js

// Always initialized (at cold-start)
const nonLazyGlobal = fileWideComputation();

// Declared at cold-start, but only initialized if/when the function executes
let lazyGlobal;

/**
 * HTTP function that uses lazy-initialized globals
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
exports.lazyGlobals = (req, res) => {
  // This value is initialized only if (and when) the function is called
  lazyGlobal = lazyGlobal || functionSpecificComputation();

  res.send(`Lazy global: ${lazyGlobal}, non-lazy global: ${nonLazyGlobal}`);
};

Python

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

def lazy_globals(request):
    """
    HTTP Cloud Function that uses lazily-initialized globals.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """
    global lazy_global, non_lazy_global

    # This value is initialized only if (and when) the function is called
    if not lazy_global:
        lazy_global = function_specific_computation()

    return 'Lazy: {}, non-lazy: {}.'.format(lazy_global, non_lazy_global)

Go


// Package tips contains tips for writing Cloud Functions in Go.
package tips

import (
	"context"
	"log"
	"net/http"
	"sync"

	"cloud.google.com/go/storage"
)

// client is lazily initialized by LazyGlobal.
var client *storage.Client
var clientOnce sync.Once

// LazyGlobal is an example of lazily initializing a Google Cloud Storage client.
func LazyGlobal(w http.ResponseWriter, r *http.Request) {
	// You may wish to add different checks to see if the client is needed for
	// this request.
	clientOnce.Do(func() {
		// Pre-declare an err variable to avoid shadowing client.
		var err error
		client, err = storage.NewClient(context.Background())
		if err != nil {
			http.Error(w, "Internal error", http.StatusInternalServerError)
			log.Printf("storage.NewClient: %v", err)
			return
		}
	})
	// Use client.
}

Esto es muy importante si defines varias funciones en un solo archivo y si varias funciones usan variables diferentes. A menos que uses la inicialización diferida, puedes perder recursos si inicializas variables que nunca se usan.

Recursos adicionales

Obtén más información sobre cómo optimizar el rendimiento en el video de “Google Cloud Performance Atlas”, Cloud Functions Cold Boot Time.