We’ve recently pushed out another minor release of the Couchbase Go SDK: 1.4.0. This is a new minor version and most notably includes support for Response Time Observability and Transparent Compression.
What’s in this release?
We’ve added support for Transparent Compression, Client Certificate Authentication and Multi Network Configurations. We’ve also added Response Time Observability that allows for seeing where time is spent in requests and identifies Orphan Responses as covered in previous blogs.
Transparent Compression
The SDK will now automatically compress and decompress documents sent to the server, if enabled on the server. This can lead to a substantial saving in both bandwidth and transmission time. By default this feature is turned on for both compression and decompression and is configured via connection string options:
- compression – boolean, whether to enable or disable client-side compression, defaults to true.
- compression_min_size – int, the minimum document size (in bytes) for a document to be considered for compression, defaults to 32 bytes.
- compression_min_ratio – float, compressed size / original size. The minimum ratio for a compressed document to be sent compressed – defaults to 0.83.
You can read more about Compression in the documentation with more of the technical details in the sdk-rfc.
Client Certificate Authentication
Client Certificate Authentication is a feature for Enterprise Edition subscribers that enables the usage of X.509 certificates for authenticating the client with Couchbase Server. This means that connections to the server are more secure and that the client can be confident that they’re only connecting to trusted servers. To use this feature a valid certificate must be setup on the server and the user identity for the client-side certificate must have roles correct assigned. The certpath and keypath should be provided in the connection string and the new CertAuthenticator{} used for cluster authentication.
1 2 3 4 5 6 7 8 9 |
cluster, err := gocb.Connect("couchbases://10.0.0.1?certpath=/path/to/chain.pem&keypath=/path/to/client.key") if err != nil { panic(err) } cluster.Authenticate(gocb.CertAuthenticator{}) bucket, err := cluster.OpenBucket("travel-sample", "") if err != nil { panic(err) } |
You can read more about Client Certificate Authentication at https://developer.couchbase.com/documentation/server/5.5/sdk/go/sdk-authentication-overview.html
Response Time Observability
These are two new, separate but also related, features designed to better understand response times and possibly diagnose where slow responses are coming from.
Response Time Observability provides information that can be used to identify unusually long running operations, helping to work out where issues are occuring – Couchbase Server, a particular node, network etc… By default a ThresholdLogTracer implementation is used but this can be swapped out for your own implementation that adheres to the OpenTracing evolving standard. To prevent filling the logs the logging defaults to a 10×10 basis. That is, the slowest 10 time outs for the last 10 seconds.
The logged output looks like:
1 |
{"service":"kv","count":10,"top":[{"operation_name":"Get","total_us":7451,"server_us":18,"decode_us":20,"last_operation_id":"0xd0a","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":5302,"server_us":22,"decode_us":17,"last_operation_id":"0x1059","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":5302,"server_us":43,"decode_us":18,"last_operation_id":"0xd63","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":4074,"server_us":117,"decode_us":17,"last_operation_id":"0xab3","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":4029,"server_us":14,"decode_us":11,"last_operation_id":"0xdfa","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":3253,"server_us":27,"decode_us":14,"last_operation_id":"0x489","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":3235,"server_us":11,"decode_us":13,"last_operation_id":"0x33b","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":3136,"server_us":14,"decode_us":13,"last_operation_id":"0xf1b","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":3132,"server_us":5,"decode_us":14,"last_operation_id":"0xea0","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"},{"operation_name":"Get","total_us":3045,"server_us":14,"decode_us":45,"last_operation_id":"0x5","last_local_id":"1d92576caf69677e/d4dbeb0069de1162"}]} |
What we see is the type of service that the log is for and how many samples we’ve taken. Let’s look at a sample in more detail:
1 2 3 4 5 6 7 8 |
{ "operation_name":"Get", "total_us":7451, "server_us":18, "decode_us":20, "last_operation_id":"0xd0a", "last_local_id":"1d92576caf69677e/d4dbeb0069de1162" } |
What we can see here is that the operation was a Get that took a total of 7.4 milliseconds of which 18 microseconds were spent on the server and 20 microseconds spent decoding the response. The last_operation_id and the last_local_id can be used to uniquely identify the request and match it up to the server logs and/or Orphan Response Logging.
You can read more about the ThresholdLogTracer and tracing at https://developer.couchbase.com/documentation/server/5.5/sdk/go/threshold-logging.html and https://developer.couchbase.com/documentation/server/5.5/sdk/go/tracing-from-the-sdk.html.
An Orphaned Response is a response received from the server for a request which has already timed out on the client. When this occurs the client still handles this response and Orphan Response Logging logs the slowest of these, along with their server durations. This is performed, by default, on the same 10×10 basis as above but is only supported for KV operations.
The logged output looks like:
1 |
{"service":"kv","count":10,"top":[{"c":"79bec7c299101f94/5f243f078b177992","i":"0x15f","r":"10.111.180.101:11210","d":10036,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x92","r":"10.111.180.101:11210","d":6239,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x85","r":"10.111.180.101:11210","d":376,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x82","r":"10.111.180.101:11210","d":135,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x67","r":"10.111.180.101:11210","d":135,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x160","r":"10.111.180.101:11210","d":126,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x44","r":"10.111.180.101:11210","d":126,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x40","r":"10.111.180.101:11210","d":126,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x5c","r":"10.111.180.101:11210","d":108,"s":"kv:CMD_GET"},{"c":"79bec7c299101f94/5f243f078b177992","i":"0x66","r":"10.111.180.101:11210","d":91,"s":"kv:CMD_GET"}]} |
As above we can see the service that the log is for and our sample size. A sample in more detail:
1 2 3 4 5 6 7 |
{ "c":"79bec7c299101f94/5f243f078b177992", "I":"0x15f", "r":"10.111.180.101:11210", "d":10036, "s":"kv:CMD_GET" } |
We can see the remote server address (r), the type of operation(s), the server duration (d) expressed in microseconds and the unique identifiers for the request (c and i). We can see that the longest timeout has a server duration of 10 milliseconds so our problem probably isn’t on the server side. Note that server duration is the time the request spent on the server side and not the total request duration.
Configuration of Orphan Response Logging is done via the cluster.Connect connection string. There are 3 configuration fields:
- orphaned_response_logging – boolean value defining whether or not to enable Orphan Response Logging, defaults to true.
- orphaned_response_logging_interval – an int value expressed in milliseconds, defines how long each logging window should be, defaults to 10 seconds.
- orphaned_response_logging_sample_size – an int value, defines how many requests to log per logging window, defaults to 10 (will always be the slowest x requests for the window).
- server_durations – boolean value defining whether or not to enable server side request durations, defaults to true and available as of Couchbase Server 5.5.
Note that in order for these 2 features to work you must be using gocb logging.
Multi Network Configuration Support
Multi Network Configuration allows the SDK to connect to clusters that expose a different set of hostnames and ports to what they use within their network internally (e.g. for when the cluster is within a different container to the application using the SDK). Support is currently considered volatile and subject to change at any time. Use of this feature is handled through a new property called network , passed in the connection string used in cluster.Connect. As of now there are 3 options that can be used with this property: auto (this is also the value used when the option is missing from the connection string or empty), default, and external.
- default – will cause the SDK to use the default hostname/ports provided for each node.
- external – will cause the SDK to use the external hostname/ports provided for each node.
- auto or property missing – will cause the SDK to attempt to work out the correct configuration to use for node.
Bug Fixes
The list of updates and fixes included in this release can be found in the release notes.
Getting it
Get the latest version using go get gopkg.in/couchbase/gocb.v1 .
Clone the repo here.