Performance of `Client#child`

Kibana uses Client#child to create an instance of the Elasticsearch client that has the authentication headers for the current end-user. As such, almost every single HTTP request to Kibana will end up calling Client#child. While doing some load testing of Kibana, the performance of Client#child is looking like a bottleneck.

During a load-test where 1000 users hit a simple HTTP Kibana API which performs authentication, I’m seeing approximately 5% of the CPU time being spent within Client#child:

The biggest culprits appear to be the use of Object.assign and ESAPI.

There are some situations where Kibana can not call Client#child until it’s absolutely needed, which definitely helps, but if we can optimize the performance of Client#child it will greatly help the general performance of Kibana.

If it’s not feasible to improve the performance of Client#child, Kibana can also potentially take advantage of the overloaded methods which support the TransportRequestOptions, but there are some potential complications with this approach.

[delvedor]

@joshdover I’m already working in that direction and I got nice results 😃 I’ll share something soon!

[joshdover]

It seems that the Object.assign behavior could be replaced with normal prototype inheritance instead. That way, not all the values have to be copied and JS can just walk the prototype chain to find the value. This may require that these option properties are not writeable so that code can’t change the parent client’s options and affect child clients.