You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a common question from the customers that arise often - how to work with the driver API in the right way if we want to produce some high load for the Tarantool cluster using it and don't get the cluster stuck, a big number of failed requests or OOM errors in the driver?
The correct answer requires some understanding of how the Tarantool instance (router) works with client requests and what are the right practices for using the concurrent framework in Java. For using the driver correctly in high-load tasks the users need to control the request rate using either the information from the Tarantool cluster monitoring or from the internal measures in the client application - the task progress and internal driver metrics. The useful driver metrics do not exist yet (it's another topic), but the request rate still can be controlled by the user.
I suggest adding an example (a benchmark script?) that uses the right code patterns for working with asynchronous futures in Java (grouping, parallel execution, exception handling) and driver API, including write, read, custom and batch calls.
The text was updated successfully, but these errors were encountered:
There is a common question from the customers that arise often - how to work with the driver API in the right way if we want to produce some high load for the Tarantool cluster using it and don't get the cluster stuck, a big number of failed requests or OOM errors in the driver?
The correct answer requires some understanding of how the Tarantool instance (router) works with client requests and what are the right practices for using the concurrent framework in Java. For using the driver correctly in high-load tasks the users need to control the request rate using either the information from the Tarantool cluster monitoring or from the internal measures in the client application - the task progress and internal driver metrics. The useful driver metrics do not exist yet (it's another topic), but the request rate still can be controlled by the user.
I suggest adding an example (a benchmark script?) that uses the right code patterns for working with asynchronous futures in Java (grouping, parallel execution, exception handling) and driver API, including write, read, custom and batch calls.
The text was updated successfully, but these errors were encountered: