On Sat, Mar 11, 2017 at 2:19 PM, Kant Kodali wrote:
> My response is inline.
>
> On Sat, Mar 11, 2017 at 1:43 PM, Avi Kivity wrote:
>
>> There are several issues at play here.
>>
>> First, a database runs a large number of concurrent operations, each of
>> which only consumes a small amount of C
There is no reason to be angry. This is progress. This is the circle of
live.
It happens anywhere at any time.
Am 12.03.2017 07:34 schrieb "Dor Laor" :
> On Sat, Mar 11, 2017 at 10:02 PM, Jeff Jirsa wrote:
>
>>
>>
>> On 2017-03-10 09:57 (-0800), Rakesh Kumar wrote:
>> > Cassanda vs Scylla is a
On Sat, Mar 11, 2017 at 10:02 PM, Jeff Jirsa wrote:
>
>
> On 2017-03-10 09:57 (-0800), Rakesh Kumar wrote:
> > Cassanda vs Scylla is a valid comparison because they both are
> compatible. Scylla is a drop-in replacement for Cassandra.
>
> No, they aren't, and no, it isn't
>
Jeff is angry with us
Why?
Am 12.03.2017 07:02 schrieb "Jeff Jirsa" :
>
>
> On 2017-03-10 09:57 (-0800), Rakesh Kumar wrote:
> > Cassanda vs Scylla is a valid comparison because they both are
> compatible. Scylla is a drop-in replacement for Cassandra.
>
> No, they aren't, and no, it isn't
>
>
>
>
>
On 2017-03-10 09:57 (-0800), Rakesh Kumar wrote:
> Cassanda vs Scylla is a valid comparison because they both are compatible.
> Scylla is a drop-in replacement for Cassandra.
No, they aren't, and no, it isn't
On Sat, Mar 11, 2017 at 9:41 PM, daemeon reiydelle
wrote:
> Recall that garbage collection on a busy node can occur minutes or seconds
> apart. Note that stop the world GC also happens as frequently as every
> couple of minutes on every node. Remove that and do the simple arithmetic.
>
>
> sent f
Recall that garbage collection on a busy node can occur minutes or seconds
apart. Note that stop the world GC also happens as frequently as every
couple of minutes on every node. Remove that and do the simple arithmetic.
sent from my mobile
Daemeon Reiydelle
skype daemeon.c.m.reiydelle
USA 415.50
My response is inline.
On Sat, Mar 11, 2017 at 1:43 PM, Avi Kivity wrote:
> There are several issues at play here.
>
> First, a database runs a large number of concurrent operations, each of
> which only consumes a small amount of CPU. The high concurrency is need to
> hide latency: disk latency
Hi,
In 99% of use cases Cassandra's row cache is not something you should look
into. Leveraging page cache yields good results and if accounted for can
provide you with performance increase on read side.
I'm not a fan of a default row cache implementation and its invalidation
mechanism on updates
There are several issues at play here.
First, a database runs a large number of concurrent operations, each of
which only consumes a small amount of CPU. The high concurrency is need
to hide latency: disk latency, or the latency of contacting a remote
node. This means that the scheduler will n
Here is the Java version http://docs.paralleluniverse.co/quasar/ but I
still don't see how user level scheduling can be beneficial (This is a well
debated problem)? How can this add to the performance? or say why is user
level scheduling necessary Given the Thread per core design and the
callback m
Scylla uses a the seastar framework, which provides for both user-level
thread scheduling and simple run-to-completion tasks.
Huge pages are limited to 2MB (and 1GB, but these aren't available as
transparent hugepages).
On 03/11/2017 10:26 PM, Kant Kodali wrote:
@Dor
1) You guys have a CPU
@Dor
1) You guys have a CPU scheduler? you mean user level thread Scheduler that
maps user level threads to kernel level threads? I thought C++ by default
creates native kernel threads but sure nothing will stop someone to create
a user level scheduling library if that's what you are talking about
Hi,
I'm new to Cassandra and trying to get a better understanding on how the
row cache can be tuned to optimize the performance.
I came across think this article:
https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html
And it suggests not to even touch row cache
Agreed, I'd recommend to treat benchmarks as a rough guide to see where
there is potential, and follow through with your own tests.
On 03/11/2017 09:37 PM, Edward Capriolo wrote:
Benchmarks are great for FUDly blog posts. Real world work loads
matter more. Every NoSQL vendor wins their benchm
Here's a test (by Samsung MSL) comparing Scylla to Cassandra 3.9:
http://www.scylladb.com/2017/02/15/scylladb-vs-cassandra-performance-benchmark-samsung/
there's a link at the end to the original report.
On 03/11/2017 09:08 PM, Bhuvan Rawal wrote:
"Lastly, why don't you test Scylla yourself? I
On Sat, Mar 11, 2017 at 2:08 PM, Bhuvan Rawal wrote:
> "Lastly, why don't you test Scylla yourself? It's pretty easy to set up,
> there's nothing to tune."
> - The details are indeed compelling to have a go ahead and test it for
> specific use case.
>
> If it works out good it can lead to good
"Lastly, why don't you test Scylla yourself? It's pretty easy to set up,
there's nothing to tune."
- The details are indeed compelling to have a go ahead and test it for
specific use case.
If it works out good it can lead to good cost cut in infra costs as well as
having to manage less servers p
There is no magic 10X bullet. It's a mix of multiple factors, which can
come up to less than 10X in some circumstances and more than 10X in
others, as has been reported on this thread by others.
TPC doesn't give _any_ advantage when you have just one core, and can
give more than 10X on a mach
Thanks a lot for your detailed explanation!
I am very curious about the future development of Scylladb! Especially
about mvs and lwt!
Am 11.03.2017 02:05 schrieb "Dor Laor" :
> On Fri, Mar 10, 2017 at 4:45 PM, Kant Kodali wrote:
>
>> http://performanceterracotta.blogspot.com/2012/09/numa-java.ht
20 matches
Mail list logo
