Re: Repair Strategies

[Adarsh Kumar]

Just a reminder, kindly provide your comments and suggestions.

On Thu, Dec 5, 2019 at 3:46 PM Adarsh Kumar  wrote:

> Hi,
>
> We are in the process of designing a new solution around cassandra. As
> repairs are very critical tasks for cassandra clusters want some pointers
> on the following:
>
>1. What are the recommended strategies for repairs for production
>cluster (>100 nodes)
>2. Is there any special consideration(s) do multi DC repairs
>3. Steps to recover a DC through repairs
>4. How much incremental repairs are useful and community
>recommendations about it(i see TLP recommendation cassandra-reaper, that
>say to use inc repair >4.0)
>
> Any link, blogs or SOP will be helpful. Thanks in advance.
>
> Thanks and regards,
> Adarsh Kumar
>

RE: Data is not syncing up when we add one more Node(DR) to existing 3 node cluster

[Anil Kumar Ganipineni]

Hi Raman,

Thanks for the response.

I will try and let you know the status. We have to do it on production 
environment, so might be it will take time to proceed.

Regards,
Anil Ganipineni

P Please consider environment before printing this page.

From: raman gugnani 
Sent: 12 December 2019 09:49
To: user@cassandra.apache.org
Subject: Re: Data is not syncing up when we add one more Node(DR) to existing 3 
node cluster

**CAUTION: This email is originated from outside the organization. Be cautious 
before opening the link or attachments. Please verify the email id and source 
of the sender.**
HI Anil,

Please follow the below link.

https://thelastpickle.com/blog/2019/02/26/data-center-switch.html

Did you ran the command nodetool rebuild old_dc_name to stream the old 
historical data to new data center.

Step 9 of the above article.


On Thu, 12 Dec 2019 at 09:39, Anil Kumar Ganipineni 
mailto:akganipin...@adaequare.com>> wrote:
Hi All,

We have 3 node cluster on datacentre DC1 and below is our key space 
declaration. The current data size on the cluster is ~10GB. When we add a new 
node on datacentre DC2, the new node is not syncing up with the data, but it is 
showing UN when I run the nodetool status.

CREATE KEYSPACE production WITH REPLICATION = { 'class' : 
'org.apache.cassandra.locator.NetworkTopologyStrategy', 'DC1': '3', 'DC2': '1' 
} AND DURABLE_WRITES = true;


Please provide suggestions to make the new node on DC2 to sync up with existing 
cluster. This is required as the DC2 is our DR in a different region other than 
existing cluster.


Regards,
Anil Ganipineni

P Please consider environment before printing this page.



--
Raman Gugnani

Re: execute is faster than execute_async?

[lampahome]

Jon Haddad  於 2019年12月12日 週四 上午12:42寫道：

> I'm not sure how you're measuring this - could you share your benchmarking
> code?
>
>> s the details of theri?
>>
>
start = time.time()
for i in range(40960):
prep = session.prepare(query, (args))
session.execute(prep) # or session.execute_async(prep)
print('time', time.time()-start)

Just like above code snippet.
I almost cost time by execute_async()   more than normal execute().

Re: Data is not syncing up when we add one more Node(DR) to existing 3 node cluster

[raman gugnani]

HI Anil,

Please follow the below link.

https://thelastpickle.com/blog/2019/02/26/data-center-switch.html

Did you ran the command nodetool rebuild old_dc_name to stream the old
historical data to new data center.

Step 9 of the above article.


On Thu, 12 Dec 2019 at 09:39, Anil Kumar Ganipineni <
akganipin...@adaequare.com> wrote:

> Hi All,
>
>
>
> We have 3 node cluster on datacentre DC1 and below is our key space
> declaration. The current data size on the cluster is ~10GB. When we add a
> new node on datacentre DC2, the new node is not syncing up with the data,
> but it is showing UN when I run the *nodetool status*.
>
>
>
> *CREATE* KEYSPACE *production* *WITH* REPLICATION = { 'class' :
> 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'DC1': '3', 'DC2':
> '1' } *AND* DURABLE_WRITES = *true*;
>
>
>
>
>
> Please provide suggestions to make the new node on DC2 to sync up with
> existing cluster. This is required as the DC2 is our DR in a different
> region other than existing cluster.
>
>
>
>
>
> *Regards,*
>
> *Anil Ganipineni*
>
>
>
> *P** Please consider environment before printing this page.*
>
>
>


-- 
Raman Gugnani

How to know execute_async correctly?

[lampahome]

I tried to execute async by batch in python-driver. But I don't know how to
check query executing correctly.

Code is like below:
B = BatchStatement()
for x in xxx:
B.add(query, (args))
res = session.execute_async(B)
B.clear() # for reusing
r = res.result()
## Then how to know my query works correctly? print(r)?


I found no doc about my question in the page of ResultSet.
Can anyone explain?

thx

average row size in a cassandra table

[Ayub M]

How to find average row size of a table in cassandra? I am not looking for
partition size (which can be found from nodetool tablehistograms), since a
partition can have many rows. I am looking for row size.

Data is not syncing up when we add one more Node(DR) to existing 3 node cluster

[Anil Kumar Ganipineni]

Hi All,

We have 3 node cluster on datacentre DC1 and below is our key space 
declaration. The current data size on the cluster is ~10GB. When we add a new 
node on datacentre DC2, the new node is not syncing up with the data, but it is 
showing UN when I run the nodetool status.

CREATE KEYSPACE production WITH REPLICATION = { 'class' : 
'org.apache.cassandra.locator.NetworkTopologyStrategy', 'DC1': '3', 'DC2': '1' 
} AND DURABLE_WRITES = true;


Please provide suggestions to make the new node on DC2 to sync up with existing 
cluster. This is required as the DC2 is our DR in a different region other than 
existing cluster.


Regards,
Anil Ganipineni

P Please consider environment before printing this page.

Re: Cassandra is not showing a node up hours after restart

[Hiroyuki Yamada]

Hello Paul,

The behavior looks similar to what we experienced and reported.
https://issues.apache.org/jira/browse/CASSANDRA-15138

In our testing, "service cassandra stop" makes a cluster sometimes in
a wrong state.
How about doing kill -9 ?

Thanks,
Hiro

On Sun, Dec 8, 2019 at 7:47 PM Hossein Ghiyasi Mehr
 wrote:
>
> Which version of Cassandra did you install? deb or tar?
> If it's deb, its script should be used for start/stop.
> If it's tar, kill pid of cassandra to stop and use bin/cassandra to start.
>
> Stop doesn't need any other actions: drain, disable gossip & etc.
>
> Where do you use Cassandra?
> ---
> VafaTech : A Total Solution for Data Gathering & Analysis
> ---
>
>
> On Fri, Dec 6, 2019 at 11:20 PM Paul Mena  wrote:
>>
>> As we are still without a functional Cassandra cluster in our development 
>> environment, I thought I’d try restarting the same node (one of 4 in the 
>> cluster) with the following command:
>>
>>
>>
>> ip=$(cat /etc/hostname); nodetool disablethrift && nodetool disablebinary && 
>> sleep 5 && nodetool disablegossip && nodetool drain && sleep 10 && sudo 
>> service cassandra restart && until echo "SELECT * FROM system.peers LIMIT 
>> 1;" | cqlsh $ip > /dev/null 2>&1; do echo "Node $ip is still DOWN"; sleep 
>> 10; done && echo "Node $ip is now UP"
>>
>>
>>
>> The above command returned “Node is now UP” after about 40 seconds, 
>> confirmed on “node001” via “nodetool status”:
>>
>>
>>
>> user@node001=> nodetool status
>>
>> Datacenter: datacenter1
>>
>> ===
>>
>> Status=Up/Down
>>
>> |/ State=Normal/Leaving/Joining/Moving
>>
>> --  Address  Load   Tokens  OwnsHost ID  
>>  Rack
>>
>> UN  192.168.187.121  539.43 GB  256 ?   
>> c99cf581-f4ae-4aa9-ab37-1a114ab2429b  rack1
>>
>> UN  192.168.187.122  633.92 GB  256 ?   
>> bfa07f47-7e37-42b4-9c0b-024b3c02e93f  rack1
>>
>> UN  192.168.187.123  576.31 GB  256 ?   
>> 273df9f3-e496-4c65-a1f2-325ed288a992  rack1
>>
>> UN  192.168.187.124  628.5 GB   256 ?   
>> b8639cf1-5413-4ece-b882-2161bbb8a9c3  rack1
>>
>>
>>
>> As was the case before, running “nodetool status” on any of the other nodes 
>> shows that “node001” is still down:
>>
>>
>>
>> user@node002=> nodetool status
>>
>> Datacenter: datacenter1
>>
>> ===
>>
>> Status=Up/Down
>>
>> |/ State=Normal/Leaving/Joining/Moving
>>
>> --  Address  Load   Tokens  OwnsHost ID  
>>  Rack
>>
>> DN  192.168.187.121  538.94 GB  256 ?   
>> c99cf581-f4ae-4aa9-ab37-1a114ab2429b  rack1
>>
>> UN  192.168.187.122  634.04 GB  256 ?   
>> bfa07f47-7e37-42b4-9c0b-024b3c02e93f  rack1
>>
>> UN  192.168.187.123  576.42 GB  256 ?   
>> 273df9f3-e496-4c65-a1f2-325ed288a992  rack1
>>
>> UN  192.168.187.124  628.56 GB  256 ?   
>> b8639cf1-5413-4ece-b882-2161bbb8a9c3  rack1
>>
>>
>>
>> Is it inadvisable to continue with the rolling restart?
>>
>>
>>
>> Paul Mena
>>
>> Senior Application Administrator
>>
>> WHOI - Information Services
>>
>> 508-289-3539
>>
>>
>>
>> From: Shalom Sagges 
>> Sent: Tuesday, November 26, 2019 12:59 AM
>> To: user@cassandra.apache.org
>> Subject: Re: Cassandra is not showing a node up hours after restart
>>
>>
>>
>> Hi Paul,
>>
>>
>>
>> From the gossipinfo output, it looks like the node's IP address and 
>> rpc_address are different.
>>
>> /192.168.187.121 vs RPC_ADDRESS:192.168.185.121
>>
>> You can also see that there's a schema disagreement between nodes, e.g. 
>> schema_id on node001 is fd2dcb4b-ca62-30df-b8f2-d3fd774f2801 and on node002 
>> it is fd2dcb4b-ca62-30df-b8f2-d3fd774f2801.
>>
>> You can run nodetool describecluster to see it as well.
>>
>> So I suggest to change the rpc_address to the ip_address of the node or set 
>> it to 0.0.0.0 and it should resolve the issue.
>>
>>
>>
>> Hope this helps!
>>
>>
>>
>>
>>
>> On Tue, Nov 26, 2019 at 4:05 AM Inquistive allen  
>> wrote:
>>
>> Hello ,
>>
>>
>>
>> Check and compare everything parameters
>>
>>
>>
>> 1. Java version should ideally match across all nodes in the cluster
>>
>> 2. Check if port 7000 is open between the nodes. Use telnet or nc commands
>>
>> 3. You must see some clues in system logs, why the gossip is failing.
>>
>>
>>
>> Do confirm on the above things.
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> On Tue, 26 Nov, 2019, 2:50 AM Paul Mena,  wrote:
>>
>> NTP was restarted on the Cassandra nodes, but unfortunately I’m still 
>> getting the same result: the restarted node does not appear to be rejoining 
>> the cluster.
>>
>>
>>
>> Here’s another data point: “nodetool gossipinfo”, when run from the 
>> restarted node (“node001”) shows a status of “normal”:
>>
>>
>>
>> user@node001=> nodetool -u gossipinfo
>>
>> /192.168.187.121
>>
>>   generation:1574364410
>>
>>   heartbeat:209150
>>
>>   NET_VERSION:8
>>
>>   RACK:rack1
>>

Re: [EXTERNAL] Re: Connection Pooling in v4.x Java Driver

[Caravaggio, Kevin]

Hi Alexandre,


Thank you for the explanation. I understand that reasoning very well now.

Jon, appreciate the link, and will follow up there for this sort of thing then.


Thanks,


Kevin
From: Alexandre Dutra 
Reply-To: "user@cassandra.apache.org" 
Date: Wednesday, December 11, 2019 at 3:33 AM
To: "user@cassandra.apache.org" 
Subject: [EXTERNAL] Re: Connection Pooling in v4.x Java Driver


*EXTERNAL SENDER*

Hi,

In driver 4.x, pools do not resize dynamically anymore because the ratio 
between concrete benefits brought by this feature and the maintenance burden it 
caused was largely unfavorable: most bugs related to connection pooling in 
driver 3.x were caused by the dynamic pool resizing. Having a fixed pool size 
made driver 4.x pool implementation much more straightforward and robust.

Thanks,

Alex Dutra


On Tue, Dec 10, 2019 at 7:13 PM Jon Haddad 
mailto:j...@jonhaddad.com>> wrote:
I'm not sure how closely the driver maintainers are following this list. You 
might want to ask on the Java Driver mailing list: 
https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user




On Tue, Dec 10, 2019 at 5:10 PM Caravaggio, Kevin 
mailto:kevin.caravag...@lowes.com>> wrote:
Hello,


When integrating with DataStax OSS Cassandra Java driver v4.x, I noticed 
“Unlike previous versions of the driver, pools do not resize 
dynamically”
 in reference to the connection pool configuration. Is anyone aware of the 
reasoning for this departure from dynamic pool sizing, which I believe was 
available in v3.x?


Thanks,


Kevin


NOTICE: All information in and attached to the e-mails below may be 
proprietary, confidential, privileged and otherwise protected from improper or 
erroneous disclosure. If you are not the sender's intended recipient, you are 
not authorized to intercept, read, print, retain, copy, forward, or disseminate 
this message. If you have erroneously received this communication, please 
notify the sender immediately by phone (704-758-1000) or by e-mail and destroy 
all copies of this message electronic, paper, or otherwise. By transmitting 
documents via this email: Users, Customers, Suppliers and Vendors collectively 
acknowledge and agree the transmittal of information via email is voluntary, is 
offered as a convenience, and is not a secured method of communication; Not to 
transmit any payment information E.G. credit card, debit card, checking 
account, wire transfer information, passwords, or sensitive and personal 
information E.G. Driver's license, DOB, social security, or any other 
information the user wishes to remain confidential; To transmit only 
non-confidential information such as plans, pictures and drawings and to assume 
all risk and liability for and indemnify Lowe's from any claims, losses or 
damages that may arise from the transmittal of documents or including 
non-confidential information in the body of an email transmittal. Thank you.


--

Alexandre Dutra  |  Technical Manager, Drivers

alexandre.du...@datastax.com  |  
datastax.com

[Image removed by 
sender.][Image
 removed by 
sender.][Image
 removed by 

Re: execute is faster than execute_async?

[Jon Haddad]

I'm not sure how you're measuring this - could you share your benchmarking
code?

I ask because execute calls execute_async under the hood:
https://github.com/datastax/python-driver/blob/master/cassandra/cluster.py#L2316

I tested the python driver a ways back and found some weird behavior due to
the way it's non blocking code was implemented.  IIRC there were some sleep
calls thrown in there to get around Python's threading inadequacies.  I
can't remember if this code path is avoided when you use the execute() call.

Jon


On Wed, Dec 11, 2019 at 3:09 AM lampahome  wrote:

> I submit 1 row for 40960 times by session.execute() and
> session.execute_async()
>
> I found total time of execute() is always fast than execute_async
>
> Does that make sense? Or I miss the details of theri?
>

Re: execute is faster than execute_async?

[Reid Pinchback]

Also note that you should be expecting async operations to be slower on a 
call-by-call basis.  Async protocols have added overhead.  The point of them 
really is to leave the client free to interleave other computing activity 
between the async calls.  It’s not usually a better way to do batch writing. 
That’s not an observation specific to C*, that’s just about understanding the 
role of async operations in computing.

There is some subtlety with distributed services like C* where you’re 
round-robining the calls around the cluster, where repeated async calls can win 
relative to sync because you aren’t waiting to hand off the next unit of work 
to a different node, but once the activity starts to queue up on any kind of 
resource, even just TCP buffering, you’ll likely be back to a situation where 
all you are measuring is the net difference in protocol overhead for async vs 
sync.

One of the challenges with performance testing is you have to be pretty clear 
on what exactly it is you are exercising, or all you can conclude from 
different numbers is that different numbers can exist.

R

From: Alexander Dejanovski 
Reply-To: "user@cassandra.apache.org" 
Date: Wednesday, December 11, 2019 at 7:44 AM
To: user 
Subject: Re: execute is faster than execute_async?

Message from External Sender
Hi,

you can check this piece of documentation from Datastax: 
https://docs.datastax.com/en/developer/python-driver/3.20/api/cassandra/cluster/#cassandra.cluster.Session.execute_async

The usual way of doing this is to send a bunch of execute_async() calls, adding 
the returned futures in a list. Once the list reaches the chosen threshold 
(usually we send around 100 queries and wait for them to finish before moving 
on the the next ones), loop through the futures and call the result() method to 
block until it completes.
Should look like this:


futures = []

for i in range(len(queries)):

futures.append(session.execute_async(queries[i]))

if len(futures) >= 100 or i == len(queries)-1:

for future in futures:

results = future.result() # will block until the query finishes

futures = []  # empty the list



Haven't tested the code above but it should give you an idea on how this can be 
implemented.
Sending hundreds/thousands of queries without waiting for a result will DDoS 
the cluster, so you should always implement some throttling.

Cheers,

-
Alexander Dejanovski
France
@alexanderdeja

Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com


On Wed, Dec 11, 2019 at 10:42 AM Jordan West 
mailto:jorda...@gmail.com>> wrote:
I’m not very familiar with the python client unfortunately. If it helps: In 
Java, async would return futures and at the end of submitting each batch you 
would block on them by calling get.

Jordan

On Wed, Dec 11, 2019 at 1:37 AM lampahome 
mailto:pahome.c...@mirlab.org>> wrote:


Jordan West mailto:jorda...@gmail.com>> 於 2019年12月11日 週三 
下午4:34寫道：
Hi,

Have you tried batching calls to execute_async with periodic blocking for the 
batch’s responses?

Can you give me some keywords about calling execute_async batch?

PS: I use python version.

[ANNOUNCE] Gemini - an automated random test suite for Scylla and Apache Cassandra

[Pekka Enberg]

Hi,

We are happy to announce Gemini, an automated random testing suite for
Scylla and Apache Cassandra clusters:

https://github.com/scylladb/gemini

We are using the tool internally to test Scylla, but there's nothing
Scylla-specific about it. The tool is written in Go and uses the gocql
driver to connect CQL-speaking clusters. The code is distributed under
the Apache 2.0 license.

Please see our blog post about the tool for more details:

https://www.scylladb.com/2019/12/11/project-gemini-an-open-source-automated-random-testing-suite-for-scylla-and-cassandra-clusters/

Regards,

- Pekka

-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Re: execute is faster than execute_async?

[Alexander Dejanovski]

Hi,

you can check this piece of documentation from Datastax:
https://docs.datastax.com/en/developer/python-driver/3.20/api/cassandra/cluster/#cassandra.cluster.Session.execute_async

The usual way of doing this is to send a bunch of execute_async() calls,
adding the returned futures in a list. Once the list reaches the chosen
threshold (usually we send around 100 queries and wait for them to finish
before moving on the the next ones), loop through the futures and call the
result() method to block until it completes.
Should look like this:

futures = []
for i in range(len(queries)):
futures.append(session.execute_async(queries[i]))
if len(futures) >= 100 or i == len(queries)-1:
for future in futures:
results = future.result() # will block until the query finishes
futures = []  # empty the list


Haven't tested the code above but it should give you an idea on how this
can be implemented.
Sending hundreds/thousands of queries without waiting for a result will
DDoS the cluster, so you should always implement some throttling.

Cheers,

-
Alexander Dejanovski
France
@alexanderdeja

Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com


On Wed, Dec 11, 2019 at 10:42 AM Jordan West  wrote:

> I’m not very familiar with the python client unfortunately. If it helps:
> In Java, async would return futures and at the end of submitting each batch
> you would block on them by calling get.
>
> Jordan
>
> On Wed, Dec 11, 2019 at 1:37 AM lampahome  wrote:
>
>>
>>
>> Jordan West  於 2019年12月11日 週三 下午4:34寫道：
>>
>>> Hi,
>>>
>>> Have you tried batching calls to execute_async with periodic blocking
>>> for the batch’s responses?
>>>
>>
>> Can you give me some keywords about calling execute_async batch?
>>
>> PS: I use python version.
>>
>

Re: Connection Pooling in v4.x Java Driver

[Alexandre Dutra]

Hi,

In driver 4.x, pools do not resize dynamically anymore because the ratio
between concrete benefits brought by this feature and the maintenance
burden it caused was largely unfavorable: most bugs related to connection
pooling in driver 3.x were caused by the dynamic pool resizing. Having a
fixed pool size made driver 4.x pool implementation much more
straightforward and robust.

Thanks,

Alex Dutra


On Tue, Dec 10, 2019 at 7:13 PM Jon Haddad  wrote:

> I'm not sure how closely the driver maintainers are following this list.
> You might want to ask on the Java Driver mailing list:
> https://groups.google.com/a/lists.datastax.com/forum/#!forum/java-driver-user
> 
>
>
>
>
> On Tue, Dec 10, 2019 at 5:10 PM Caravaggio, Kevin <
> kevin.caravag...@lowes.com> wrote:
>
>> Hello,
>>
>>
>>
>>
>>
>> When integrating with DataStax OSS Cassandra Java driver v4.x, I noticed 
>> “Unlike
>> previous versions of the driver, pools do not resize dynamically”
>> 
>> in reference to the connection pool configuration. Is anyone aware of the
>> reasoning for this departure from dynamic pool sizing, which I believe was
>> available in v3.x?
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>>
>>
>> Kevin
>>
>>
>> --
>> NOTICE: All information in and attached to the e-mails below may be
>> proprietary, confidential, privileged and otherwise protected from improper
>> or erroneous disclosure. If you are not the sender's intended recipient,
>> you are not authorized to intercept, read, print, retain, copy, forward, or
>> disseminate this message. If you have erroneously received this
>> communication, please notify the sender immediately by phone (704-758-1000)
>> or by e-mail and destroy all copies of this message electronic, paper, or
>> otherwise. By transmitting documents via this email: Users, Customers,
>> Suppliers and Vendors collectively acknowledge and agree the transmittal of
>> information via email is voluntary, is offered as a convenience, and is not
>> a secured method of communication; Not to transmit any payment information
>> E.G. credit card, debit card, checking account, wire transfer information,
>> passwords, or sensitive and personal information E.G. Driver's license,
>> DOB, social security, or any other information the user wishes to remain
>> confidential; To transmit only non-confidential information such as plans,
>> pictures and drawings and to assume all risk and liability for and
>> indemnify Lowe's from any claims, losses or damages that may arise from the
>> transmittal of documents or including non-confidential information in the
>> body of an email transmittal. Thank you.
>>
>

-- 

Alexandre Dutra  |  Technical Manager, Drivers

alexandre.du...@datastax.com  |  datastax.com 


 
 

Re: execute is faster than execute_async?

[Jordan West]

I’m not very familiar with the python client unfortunately. If it helps: In
Java, async would return futures and at the end of submitting each batch
you would block on them by calling get.

Jordan

On Wed, Dec 11, 2019 at 1:37 AM lampahome  wrote:

>
>
> Jordan West  於 2019年12月11日 週三 下午4:34寫道：
>
>> Hi,
>>
>> Have you tried batching calls to execute_async with periodic blocking for
>> the batch’s responses?
>>
>
> Can you give me some keywords about calling execute_async batch?
>
> PS: I use python version.
>

Re: execute is faster than execute_async?

[lampahome]

Jordan West  於 2019年12月11日 週三 下午4:34寫道：

> Hi,
>
> Have you tried batching calls to execute_async with periodic blocking for
> the batch’s responses?
>

Can you give me some keywords about calling execute_async batch?

PS: I use python version.

Re: execute is faster than execute_async?

[Jordan West]

Hi,

Have you tried batching calls to execute_async with periodic blocking for
the batch’s responses? I’ve witnessed this behavior as well with large or
no batches and while I didn’t have time to investigate fully its likely due
to message queuing behavior within Cassandra (pre-4.0). Smaller batches or
execute() alleviates the queueing issues and spreads the load more evenly
across the time quanta being measured.

Jordan


On Wed, Dec 11, 2019 at 12:09 AM lampahome  wrote:

> I submit 1 row for 40960 times by session.execute() and
> session.execute_async()
>
> I found total time of execute() is always fast than execute_async
>
> Does that make sense? Or I miss the details of theri?
>

execute is faster than execute_async?

[lampahome]

I submit 1 row for 40960 times by session.execute() and
session.execute_async()

I found total time of execute() is always fast than execute_async

Does that make sense? Or I miss the details of theri?