How to increase Number of connections from external client SDKs?
Couchbase Console > Server Resources > Server Resources
Number of connections to this server includingconnections from external
client SDKs, proxies, TAP requests and internal statistic gathering
(measured from curr_connections)
Generally we try to use as few connections as possible and get the most out of those resources. For instance, this is done through asynchronous IO from calling threads/actors muxing over the connections.
Unless I misunderstand the question, there should be no need to increase the number of connections.
Thanks we are not using asynchronous we will try asynchronous latter .
In a synchronous use case how would we increase connection pool if we like to do it ?
@GeorgeLeon I think you misunderstood what @ingenthr was saying. the client internally will perform all operations asynchronously, all the time. We are not using blocking IO internally, so the idea of a connection pool is different than what you’d know from traditional JDBC drivers, for example. Async IO is much more performant in dealing with many connections internally, also giving better batching performance.
So let me rephrase: what is the problem you are trying to solve by using something like a connection pool?
Currently focusing on synchronous bucket operations ( I will try asynchronous later) .
My current objective is to see increase of SDK client connections . Is this possible ?
Currently I use the recommended way one singleton to connect via DefaultCouchbaseEnvironment as is (i.e. no extra configurations). And I get 3-4 connections per client app.
Basically I like to push Couchbase to its limits to use all the available resources ( memory, CPU) in a small cluster I 'm testing. (4 cores each node 1 data/ 2 index/ 1 query )
Caused by: javax.ejb.EJBTransactionRolledbackException: The Content of this Observable is already released. Subscribe earlier or tune the CouchbaseEnvironment#autoreleaseAfter() setting.
and
Caused by: java.lang.RuntimeException: java.util.concurrent.TimeoutException
at com.couchbase.client.java.util.Blocking.blockForSingle(Blocking.java:75) [java-client-2.2.1.jar:]
at com.couchbase.client.java.CouchbaseBucket.get(CouchbaseBucket.java:111) [java-client-2.2.1.jar:]
at com.couchbase.client.java.CouchbaseBucket.get(CouchbaseBucket.java:106) [java-client-2.2.1.jar:]
and Couchbase CPU at 7% so our conclusion is that the SDK is limiting access to Couchbase server .
The two exceptions are different. Can you share the code paths for both when they happen? Do you have a custom timeout set?
In 2.2.1 we have new metrics built in, you can read more about it here: Couchbase SDKs - tune the intervals down a bit if you want and then please post the logged histograms somewhere we can inspect it!
I understand that the SDK via Rest API that is async.
I mix up the traditional sense JDBC and the new async way via Rest API .
Thank you for your time I will get back to reality and scale down my test and follow the recommendations in the docs.
And get back if needed
My main task is
To review for senior management if can get the performance we need out of Couchbase before we commit to this solution.
Our requirement is for 10K concurrent users what kind of a cluster we will need.
Any suggestions on what i can do to get a baseline of what can i get out of Couchbase / Java SDK for the following set-up.
I’m interested to better understand the limits for database access (read/write/query) via Java SDK and Couchbase for a small cluster
( 4 cores each node 1 data/ 2 index/ 1 query ) with 6 indexes for N1QL and 1 million documents or something similar if any official benchmarks I can see on the Java SDK with Couchbase can also help .
Some information on what I am doing,
Basically we have messos cluster with Wildlflies (Jboss) with Rest API that use stateless EJBs pool that then hit the couchbase DAO that uses CB Java SDK and that hits CB Database.
I am testing/trying with different scenarios of concurrent API calls / Wildlfy thread pool numbers / Ejb pool numbers …
We find that increasing the concurrent Restful API calls to 5K - 10K for example on a logon operation
we get the 2 error I previously sent . Thus I assume what the DefaultCouchbaseEnvironment needs tweaking or
we have reached the limits of the our stack . This is what I don’t know and I don’t want to make an assumption as to make my conclusion wrong .
Okay so from your answer I get to understand that once you ramp up load, you get timeouts.
Before tuning anything, we need to get a better understand of why you actually see timeouts, there are so many reasons it can happen. So I still recommend the following:
Can you run a JMC/JFR recording of the system under load/test and then share it? You can also do all of this via PM here to me privately if you don’t want to share it.