Recientemente hemos lanzado otra versión menor del SDK de Couchbase Go: 1.4.0. Se trata de una nueva versión menor que incluye soporte para Response Time Observability y Transparent Compression.

¿Qué contiene esta versión?

Hemos añadido soporte para Compresión Transparente, Autenticación de Certificados de Cliente y Configuraciones Multi Red. También hemos añadido la capacidad de observación del tiempo de respuesta, que permite ver dónde se invierte el tiempo en las solicitudes e identifica las respuestas huérfanas, como se explica en blogs anteriores.

Compresión transparente

El SDK ahora comprimirá y descomprimirá automáticamente los documentos enviados al servidor, si está habilitado en el servidor. Esto puede suponer un ahorro sustancial tanto en ancho de banda como en tiempo de transmisión. Por defecto, esta función está activada tanto para la compresión como para la descompresión y se configura a través de las opciones de la cadena de conexión:

  • compresión  - booleano, para activar o desactivar la compresión del lado del cliente, por defecto es true.
  • tamaño_min de_compresión  - int, el tamaño mínimo del documento (en bytes) para que un documento sea considerado para la compresión, por defecto 32 bytes.
  • relación_mín_de_compresión  - float, tamaño comprimido / tamaño original. Proporción mínima para que un documento comprimido se envíe comprimido - por defecto 0,83.

Puede obtener más información sobre la compresión en documentación con más detalles técnicos en el sdk-rfc.

Autenticación de certificados de cliente

Client Certificate Authentication es una característica para los suscriptores de Enterprise Edition que permite el uso de certificados X.509 para autenticar al cliente con Couchbase Server. Esto significa que las conexiones al servidor son más seguras y que el cliente puede estar seguro de que sólo se conecta a servidores de confianza. Para usar esta característica un certificado válido debe ser configurado en el servidor y la identidad del usuario para el certificado del lado del cliente debe tener roles correctamente asignados. La dirección certpath  y ruta de acceso  en la cadena de conexión y el nuevo CertAuthenticator{}  utilizado para la autenticación del clúster.

Puede obtener más información sobre la autenticación de certificados de cliente en https://developer.couchbase.com/documentation/server/5.5/sdk/go/sdk-authentication-overview.html

Tiempo de respuesta Observabilidad

Se trata de dos nuevas funciones, distintas pero también relacionadas, diseñadas para comprender mejor los tiempos de respuesta y, posiblemente, diagnosticar de dónde proceden las respuestas lentas.

La Observabilidad del Tiempo de Respuesta proporciona información que puede ser usada para identificar operaciones inusualmente largas, ayudando a averiguar dónde están ocurriendo los problemas - Couchbase Server, un nodo en particular, la red, etc... Por defecto se usa una implementación de ThresholdLogTracer pero esta puede ser cambiada por tu propia implementación que se adhiera al estándar en evolución OpenTracing. Para evitar que se llenen los registros, el registro se realiza por defecto sobre una base de 10×10. Es decir, los 10 tiempos de espera más lentos de los últimos 10 segundos.

La salida registrada tiene el siguiente aspecto:

Lo que vemos es el tipo de servicio al que corresponde el registro y cuántas muestras hemos tomado. Veamos una muestra con más detalle:

Lo que podemos ver aquí es que la operación fue un Get que tomó un total de 7.4 milisegundos de los cuales 18 microsegundos fueron gastados en el servidor y 20 microsegundos gastados decodificando la respuesta. El last_operation_id y el last_local_id pueden usarse para identificar de forma única la petición y compararla con los registros del servidor y/o el registro de respuestas huérfanas.

Puede obtener más información sobre ThresholdLogTracer y el rastreo en https://developer.couchbase.com/documentation/server/5.5/sdk/go/threshold-logging.html y https://developer.couchbase.com/documentation/server/5.5/sdk/go/tracing-from-the-sdk.html.

Una Respuesta Huérfana es una respuesta recibida del servidor para una petición que ya ha expirado en el cliente. Cuando esto ocurre, el cliente sigue gestionando esta respuesta y el registro de respuestas huérfanas registra las más lentas, junto con su duración en el servidor. Esto se realiza, por defecto, sobre la misma base de 10×10 que antes, pero sólo se admite para operaciones KV.

La salida registrada tiene el siguiente aspecto:

Como en el caso anterior, podemos ver el servicio al que corresponde el registro y el tamaño de nuestra muestra. Una muestra con más detalle:

Podemos ver la dirección del servidor remoto (r), el tipo de operación(es), la duración del servidor (d) expresada en microsegundos y los identificadores únicos de la petición (c e i). Podemos ver que el tiempo de espera más largo tiene una duración del servidor de 10 milisegundos, por lo que nuestro problema probablemente no esté en el lado del servidor. Tenga en cuenta que la duración del servidor es el tiempo que la solicitud pasó en el lado del servidor y no la duración total de la solicitud.

La configuración del registro de respuestas huérfanas se realiza a través de la cadena de conexión cluster.Connect. Hay 3 campos de configuración:

  • registro_de_respuestas_huérfanas  - valor booleano que define si se activa o no el registro de respuestas huérfanas, por defecto es true.
  • intervalo_de_registro_de_respuestas_huérfanas  - un valor int expresado en milisegundos, define la duración de cada ventana de registro, por defecto 10 segundos.
  • tamaño_de_la_muestra_de_registro_de_respuesta_huérfana  - un valor int, define cuántas peticiones registrar por ventana de registro, por defecto 10 (siempre serán las x peticiones más lentas de la ventana).
  • duración_del_servidor  - valor booleano que define si se habilita o no la duración de las peticiones del lado del servidor, por defecto es true y está disponible a partir de Couchbase Server 5.5.

Tenga en cuenta que para que estas 2 funciones funcionen debe estar utilizando registro gocb.

Soporte de configuración multired

Multi Network Configuration permite al SDK conectarse a clusters que exponen un conjunto de nombres de host y puertos diferentes a los que utilizan dentro de su red internamente (por ejemplo, para cuando el cluster está dentro de un contenedor diferente al de la aplicación que utiliza el SDK). La ayuda se considera actualmente volátil y está sujeta a cambios en cualquier momento. El uso de esta función se gestiona a través de una nueva propiedad denominada red que se pasa en la cadena de conexión utilizada en cluster.Connect. A partir de ahora hay 3 opciones que se pueden utilizar con esta propiedad: auto (este es también el valor utilizado cuando la opción falta en la cadena de conexión o está vacía), default y external.

  • por defecto  - hará que el SDK utilice el nombre de host/puertos por defecto proporcionados para cada nodo.
  • externo  - hará que el SDK utilice el nombre de host externo/puertos proporcionados para cada nodo.
  • auto o falta de propiedad - hará que el SDK intente averiguar la configuración correcta a utilizar para el nodo.

Corrección de errores

La lista de actualizaciones y correcciones incluidas en esta versión puede consultarse en la página notas de la versión.

Conseguirlo

Obtenga la última versión utilizando ir consiga gopkg.en/couchbase/gocb.v1 .

Clonar el repositorio aquí.

Autor

Publicado por Charles Dixon, Ingeniero de Software, Couchbase

Charles Dixon es Ingeniero de Software en Couchbase. Trabaja en el SDK de Couchbase Go.

Dejar una respuesta