You're quite right. I missed important thing first. I found a mistake in my program while making test case. It turns out that the original program has 3~4 selects for non-existing row keys plus a select for existing row key. It was intended to do nothing but for next tests. My original test counted only selects for existing row key but opscenter graph showed real number of request. That's it
Thank you again ~ On 24 April 2015 at 16:01, Carlos Rolo <r...@pythian.com> wrote: > Let me try to reproduce your test and get back wiith some results. > > Regards, > > Carlos Juzarte Rolo > Cassandra Consultant > > Pythian - Love your data > > rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo > <http://linkedin.com/in/carlosjuzarterolo>* > Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649 > www.pythian.com > > On Fri, Apr 24, 2015 at 2:35 AM, Bongseo Jang <grayce...@gmail.com> wrote: > >> Thanks a lot Carlos, Sebastian :-) >> >> My test was with 1 node/1 replica settings, on which I assumed client >> request = read request on the graph. Because there seems no read_repair and >> already CL=ONE in my case, I need more explanation, don't I? Or can any >> other internals be still involved? >> >> Do you have more suggestions? I want to design new test narrowing the gap >> on the suggestions. >> >> On 24 April 2015 at 00:23, Sebastian Estevez < >> sebastian.este...@datastax.com> wrote: >> >>> Carlos is right: >>> >>> *Read Requests* - The number of read requests per second on the >>> coordinator nodes, analogous to client reads. Monitoring the number of >>> requests over a given time period reveals system read workload and usage >>> patterns. >>> >>> *Avg* - The average of values recorded during a time interval. >>> >>> A future version of OpsC will include tooltips with these descriptions >>> for better clarity. >>> On Apr 23, 2015 6:30 AM, "Carlos Rolo" <r...@pythian.com> wrote: >>> >>>> Probably it takes in account the read repair, plus a read that have >>>> consistency != 1 will produce reads on other machines (which are taken in >>>> account). I don't know the internals of opscenter but I would assume that >>>> this is the case. >>>> >>>> If you want to test it further, disable read_repair, and make all your >>>> reads with CL=ONE. Then your client and Opscenter should match. >>>> >>>> PS: Speculative_retry could also send reads over to more machines. >>>> >>>> Regards, >>>> >>>> Carlos Juzarte Rolo >>>> Cassandra Consultant >>>> >>>> Pythian - Love your data >>>> >>>> rolo@pythian | Twitter: cjrolo | Linkedin: >>>> *linkedin.com/in/carlosjuzarterolo >>>> <http://linkedin.com/in/carlosjuzarterolo>* >>>> Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649 >>>> www.pythian.com >>>> >>>> On Thu, Apr 23, 2015 at 10:34 AM, Bongseo Jang <grayce...@gmail.com> >>>> wrote: >>>> >>>>> I have cassandra 2.1 + OpsCenter 5.1.1 and test them. >>>>> >>>>> When I monitored with opscenter 'read requests' graph, it seems the >>>>> number on the graph is not what I expected, the number of client requests >>>>> or responses. >>>>> >>>>> I recorded actual number of client request and compare it with graph, >>>>> then found they're different. The number on the graph is about 4 times >>>>> larger than what the client claimed. >>>>> >>>>> So, my question is what 'Read Reuqests' on OpsCenter counts exaclty ? >>>>> >>>>> Thanks ! >>>>> >>>>> -- >>>>> Regards, >>>>> Jang. >>>>> >>>>> a sound mind in a sound body >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> >> >> >> -- >> Regards, >> Jang. >> >> a sound mind in a sound body >> > > > -- > > > > -- Regards, Jang. a sound mind in a sound body
