Latency can be so variable even when testing things locally. I quickly
fired up postgres and did the following with psql:
ben=# CREATE TABLE foo(i int, j text, PRIMARY KEY(i));
CREATE TABLE
ben=# \timing
Timing is on.
ben=# INSERT INTO foo VALUES(2, 'yay');
INSERT 0 1
Time: 1.162 ms
ben=# INSERT INTO foo VALUES(3, 'yay');
INSERT 0 1
Time: 1.108 ms
I then fired up a local copy of Cassandra (2.0.12)
cqlsh> CREATE KEYSPACE foo WITH replication = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> USE foo;
cqlsh:foo> CREATE TABLE foo(i int PRIMARY KEY, j text);
cqlsh:foo> TRACING ON;
Now tracing requests.
cqlsh:foo> INSERT INTO foo (i, j) VALUES (1, 'yay');
Tracing session: 7a7dced0-d4b2-11e4-b950-85c3c9bd91a0
activity | timestamp | source
| source_elapsed
---------------------------------------------------+--------------+-----------+----------------
execute_cql3_query | 11:52:55,229 |
127.0.0.1 | 0
Parsing INSERT INTO foo (i, j) VALUES (1, 'yay'); | 11:52:55,229 |
127.0.0.1 | 43
Preparing statement | 11:52:55,229 |
127.0.0.1 | 141
Determining replicas for mutation | 11:52:55,229 |
127.0.0.1 | 291
Acquiring switchLock read lock | 11:52:55,229 |
127.0.0.1 | 403
Appending to commitlog | 11:52:55,229 |
127.0.0.1 | 413
Adding to foo memtable | 11:52:55,229 |
127.0.0.1 | 432
Request complete | 11:52:55,229 |
127.0.0.1 | 541
All this on a mac book pro with 16gb of memory and an SSD
So ymmv?
On 27 March 2015 at 08:28, Tyler Hobbs <ty...@datastax.com> wrote:
> Just to check, are you concerned about minimizing that latency or
> maximizing throughput?
>
> I'll that latency is what you're actually concerned about. A fair amount
> of that latency is probably happening in the python driver. Although it
> can easily execute ~8k operations per second (using cpython), in some
> scenarios it can be difficult to guarantee sub-ms latency for an individual
> query due to how some of the internals work. In particular, it uses
> python's Conditions for cross-thread signalling (from the event loop thread
> to the application thread). Unfortunately, python's Condition
> implementation includes a loop with a minimum sleep of 1ms if the Condition
> isn't already set when you start the wait() call. This is why, with a
> single application thread, you will typically see a minimum of 1ms latency.
>
> Another source of similar latencies for the python driver is the Asyncore
> event loop, which is used when libev isn't available. I would make sure
> that you can use the LibevConnection class with the driver to avoid this.
>
> On Fri, Mar 27, 2015 at 6:24 AM, Artur Siekielski <a...@vhex.net> wrote:
>
>> I'm running Cassandra locally and I see that the execution time for the
>> simplest queries is 1-2 milliseconds. By a simple query I mean either
>> INSERT or SELECT from a small table with short keys.
>>
>> While this number is not high, it's about 10-20 times slower than
>> Postgresql (even if INSERTs are wrapped in transactions). I know that the
>> nature of Cassandra compared to Postgresql is different, but for some
>> scenarios this difference can matter.
>>
>> The question is: is it normal for Cassandra to have a minimum latency of
>> 1 millisecond?
>>
>> I'm using Cassandra 2.1.2, python-driver.
>>
>>
>>
>
>
> --
> Tyler Hobbs
> DataStax <http://datastax.com/>
>
--
Ben Bromhead
Instaclustr | www.instaclustr.com | @instaclustr
<http://twitter.com/instaclustr> | (650) 284 9692
