Pruebas de rendimiento gRPC con k6: Protobuf, streaming y timeouts

Tus microservicios hablan gRPC sobre HTTP/2—fuertemente tipados, multiplexados e invisibles a smokes basados en curl. Scripts de carga REST pierden CPU de serialización, backpressure de streaming y propagación de deadline que dominan latencia de cola bajo concurrencia. El módulo gRPC de k6 carga descriptores protobuf y ejecuta RPCs unary o streaming como clientes de producción.

Pruebas de rendimiento gRPC no son REST con otro puerto. Es diseño de escenario por forma de RPC: hot paths unary vs feeds server-streaming vs sesiones bidireccionales—cada una con matemática VU y modos de fallo distintos. En esta guía verás dónde se esconden cuellos gRPC, cómo estructurar escenarios k6 con deadlines y tags, y qué señales deben gatear releases—no solo «RPC devuelve OK una vez».

Por qué latencia gRPC diverge de supuestos REST

Servicios protobuf parecen simples en archivos .proto. Bajo carga, el comportamiento difiere de HTTP JSON:

• Costo de serialización mueve CPU a marshal/unmarshal—especialmente campos repeated grandes.
• Multiplexing HTTP/2 comparte conexiones; head-of-line blocking se comporta distinto que pools REST (pruebas HTTP/2).
• RPCs streaming acumulan backpressure—consumidores lentos frenan productores.
• Deadlines y cancelación se propagan—o no—a través de cadenas de hops (deadlines gRPC).
• Keepalive y max concurrent streams en channels afectan churn de conexión bajo muchos VUs.

Piensa gRPC como llamada telefónica con transcripciones tipadas: la eficiencia del wire ayuda hasta que alguien mantiene la línea abierta en un server stream que nadie lee.

Implementación práctica en k6: escenarios unary vs streaming

Carga RPCs unary respaldados por descriptor para SLOs de throughput; agrega escenario streaming baja tasa para latencia de cola y detección de cuelgues.

Script de ejemplo (ilustrativo—no listo para producción). Coloca service.proto y descriptor generado junto al script según docs k6.

Qué demuestra este ejemplo:

• Cliente con proto cargado: grpc.load() conecta con opciones TLS e invoca métodos por nombre fully qualified.
• Hot path unary: GetOrder a alta arrival rate con metadata deadline.
• Sonda server-streaming: escenario separado con menos VUs observa streams atascados.
• Tags y umbrales por RPC: rpc:GetOrder vs rpc:WatchInventory segmentan métricas.

import grpc from 'k6/grpc';
import { check, sleep } from 'k6';

const client = new grpc.Client();
client.load(['./proto'], 'inventory.proto');

const HOST = __ENV.GRPC_HOST || 'grpc-staging.example.com:443';

export const options = {
  scenarios: {
    unary_orders: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.UNARY_RPS || 40),
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 15,
      maxVUs: 80,
      exec: 'getOrder',
      tags: { rpc: 'GetOrder', pattern: 'unary' },
    },
    stream_watch: {
      executor: 'constant-vus',
      vus: 3,
      duration: '5m',
      exec: 'watchInventory',
      tags: { rpc: 'WatchInventory', pattern: 'server_streaming' },
    },
  },
  thresholds: {
    'grpc_req_duration{rpc:GetOrder}': ['p(95)<120', 'p(99)<250'],
    'grpc_req_duration{rpc:WatchInventory}': ['p(95)<500'],
    checks: ['rate>0.99'],
  },
};

export function getOrder() {
  client.connect(HOST, { tls: true });
  const response = client.invoke('inventory.OrderService/GetOrder', {
    order_id: `ORD-${__VU}-${__ITER}`,
  }, { metadata: { deadline: '500ms' } });

  check(response, {
    'GetOrder status OK': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
  sleep(0.1);
}

export function watchInventory() {
  client.connect(HOST, { tls: true });
  const stream = client.invoke('inventory.InventoryService/WatchInventory', {
    sku: 'SKU-100',
  }, { metadata: { deadline: '2s' } });

  check(stream, {
    'stream started': (r) => r && r.status === grpc.StatusOK,
  });
  client.close();
  sleep(1);
}

Patrones que funcionan

• Un escenario por patrón RPC—unary, client-stream, server-stream, bidi (tipos escenario k6).
• Deadlines en metadata reflejan políticas cliente prod—detecta propagación faltante temprano.
• Descriptor en git versionado con servicio—regenera cuando cambia .proto.
• Empareja con métricas service mesh y correlation IDs para traces.

Anti-patrones a evitar

• Reutilizar umbrales REST http_req_duration para gRPC sin baseline.
• Un mega-stream por VU forever—enmascara lag consumidor hasta prod.
• Saltar TLS/opciones que clientes prod usan—distorsiona comportamiento de conexión.

Pro tip (comando de ejemplo):

k6 run grpc-inventory.js --summary-trend-stats="p(95),p(99)" -e UNARY_RPS=60

Qué demuestra este comando: ajusta throughput unary independientemente mientras observas escenario streaming por cuelgues en la misma corrida.

Marco de decisión: foco unary vs stress streaming

Usa escenarios unary-heavy si SLOs producto cubren solo RPCs request/response.

Usa escenarios streaming si incidentes involucraron streams atascados, crecimiento memoria o lag consumidor.

Usa tests HTTP gateway si clientes pegan REST pero riesgo perf es gRPC interno—prueba ambas capas.

Observabilidad, documentación y próximos pasos

Tests carga gRPC necesitan disciplina de versión proto. Antes de tráfico pico:

• Documenta git SHA proto, path descriptor y política deadline por RPC en runbook.
• Alerta cuando grpc_req_duration{rpc:*} cruce SLO—separado de dashboards REST.
• Correlaciona tags RPC k6 con spans gRPC OpenTelemetry en staging.
• Automatiza smoke unary en CI tras merges proto (pruebas de carga en CI/CD).
• Archiva JSON escenario y UNARY_RPS por release para comparar regresiones.

Cómo Performate simplifica pruebas de carga gRPC

Paths protobuf y opciones TLS frenan equipos acostumbrados a HTTP Postman. Abajo un ejemplo de flujo concreto para servicios gRPC order/inventory.

Ejemplo: throughput unary + sonda streaming en un workspace

1. Documenta host gRPC, path proto y payloads sample en notas de escenario (import HTTP Performate para edge gateway si aplica). Problema resuelto: onboarding sin cazar páginas wiki.
2. Crea escenario unary_orders con arrival rate de analytics prod. Problema resuelto: tuning throughput sin reescribir boilerplate executor.
3. Agrega escenario bajo-VU stream_watch con think time largo entre aperturas stream. Problema resuelto: riesgo streaming visible junto a dashboards unary.
4. Aplica tags rpc:* y pattern:unary|server_streaming como el ejemplo k6. Problema resuelto: reportes segmentan por forma RPC.
5. Corre en staging, exporta reporte integrado para sign-off owner servicio. Problema resuelto: un artefacto para backend y platform.
6. Exporta script k6 gRPC para smoke CI tras cambios proto. Problema resuelto: ediciones escritorio y pipeline alineados.

Ese flujo mapea al cta: escenarios ejecutables, umbrales y reportes compartibles sin sprints de glue code.

Cierre

Rendimiento gRPC es problema de forma RPC: throughput unary, backpressure streaming y deadlines necesitan escenario propio. Prueba con descriptores cargados, taggea cada método, y trata streams atascados como gates de release—no extras opcionales.

Corre la tasa unary de esta semana contra staging—y mantén el escenario streaming el tiempo suficiente para detectar lag consumidor que tus tests REST nunca vieron.

Try Performate free | Reserva una demo | Módulo gRPC k6