Thanks, Stack, I still cannot figure out the root cause. I am not familiar with thread-dumping or profiler. Is there any reference that I can study about how to use those tools to analyze this kind of issue? Or is there some similar performance test that I can refer to? Maybe my test is wrong. I just write a simple java program to get a row from a table in a loop. And by spawning this program from 1 to 200, and check the response time. I just observed that all resources CPU, memory,. I/O are still idle, but the avg response time for a single request (put/get) become slower when the concurrency increasing. All the request goes to the same region in my test. So I am trying to understand those parameters.
Thanks, Ming -----Original Message----- From: Stack <[email protected]> Sent: Thursday, January 17, 2019 3:17 AM To: Hbase-User <[email protected]> Subject: Re: coprocessor and hbase.regionserver.handler.count On Mon, Jan 14, 2019 at 5:37 PM ming.liu <[email protected]> wrote: > Hi, all, > > > > Our application is using coprocessor to communicate with HBase, not using > the get()/put() client API. When there are large concurrency, the > performance is degrading very fast. > > Can you figure why? Thread-dumping, profiler? > I checked there is hbase.regionserver.handler.count which control how many > thread in RS to handle client request. Will coprocessor use those same > threads? > > Yes. CPs decorate the existing read/write paths serviced by handlers. S > > > thanks, > > Ming > > > >
