Yes I am well aware of Scyalldb. It might be well written in C++ but the performance gain they are claiming has very little to do with moving from Java to C++. They had major design changes such as moving away from SEDA to TPC and so on. Moreover I would say it still needs to mature. Lot of users had complained that they cannot get the benchmarks similar to the ones that are posted online and I keep seeing comments stating that you need to use a specific hardware and specific tuning mechanisms and so on (I don't mean to say what scylladb is claiming is wrong I certainly haven't verified it but I do know for the fact lot of people are having trouble to reach those benchmarks).
SEDA to TPC is a very big change. Let's see how long it would take for Apache C* https://issues.apache.org/jira/browse/CASSANDRA-10989 On Sat, Nov 26, 2016 at 11:45 PM, Benjamin Roth <benjamin.r...@jaumo.com> wrote: > You are of course right. There is no solution and no language that is a > perfect match for every situation and every solution and language has it's > own pros, cons, pitfalls and drawbacks. > Actually that article you posted points at some aspect of ARC, I wasn't > aware of, yet. > Nevertheless, GC is an issue for Cassandra, otherwise this thread would > not exist, right? But we have to deal with it and get the best out of it. > > Another option, besides optimizing your GC: You could check if > http://www.scylladb.com/ is an option for you. > They rewrote CS from the scratch. The goal is to be completely compatible > with CS but to be much, much faster. Check their benchmarks and their > architecture. > I really do not want do depreciate the work of all the Cassandra > Developers - they did a great job - but what I have seen there looked very > interesting and promising! By the way it's written in C++. > > > 2016-11-27 7:06 GMT+01:00 Kant Kodali <k...@peernova.com>: > >> Automatic Reference counting sounds like college level idea that we all >> have been hearing for since GC is born! There seem to be bunch of cons of >> ARC as explained here >> >> https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memor >> y-management-method-of-garbage-collection-like-in-Java >> >> Maintaining C and C++ APPS are never a pain? How about versioning and >> static time libraries? There is work there too. so its all pros and cons >> >> "gc is a pain in the ass". How about seg faults? they aren't any lesser >> pain :) >> >> Not only Cassandra that runs on JVM. Majority of Apache projects do run >> on JVM for a reason. >> >> Bottom line. My point here is there are pros and cons of every language. >> It doesn't make much sense to target one language. >> >> >> >> >> >> >> On Sat, Nov 26, 2016 at 9:31 PM, Benjamin Roth <benjamin.r...@jaumo.com> >> wrote: >> >>> Arc means Automatic Reference counting which is done at compilen time. >>> Eg Objektive c and Swift use this technique. There are absolutely No gc's. >>> Its a completely different memory Management technique. >>> >>> Why i dont like Java on Server side? Because gc is a pain in the ass. I >>> am doing this Business since over 15 years and running/maintaining Apps >>> that are build in c or c++ has never been such a pain. >>> >>> On the other Hand Java is easier to handle for Developers. And coding >>> plain c is also a pain. >>> >>> Thats why i Said its a philosophic discussion. >>> Anyway Cassandra rund on Java so We have to Deal with it. >>> >>> Am 27.11.2016 05:28 schrieb "Kant Kodali" <k...@peernova.com>: >>> >>>> Benjamin Roth: How do you know Arc eliminates GC pauses completely? By >>>> completely I mean no GC pauses whatsoever. >>>> >>>> When you say Java is NOT the First choice for Server Applications you >>>> are generalizing it too much I would say since many of them fall under that >>>> category. Either way the statement you made is purely subjective. >>>> >>>> On Fri, Nov 25, 2016 at 2:41 PM, Benjamin Roth <benjamin.r...@jaumo.com >>>> > wrote: >>>> >>>>> Lol. The counter proof is to use another memory Model like Arc. Thats >>>>> why i personally think Java is NOT the First choice for Server >>>>> Applications. But thats a philosophic discussion. >>>>> >>>>> Am 25.11.2016 23:38 schrieb "Kant Kodali" <k...@peernova.com>: >>>>> >>>>>> +1 Chris Lohfink response >>>>>> >>>>>> I would also restate the following sentence "java GC pauses are >>>>>> pretty much a fact of life" to "Any GC based system pauses are >>>>>> pretty much a fact of life". >>>>>> >>>>>> I would be more than happy to see if someone can counter prove. >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Nov 25, 2016 at 1:41 PM, Chris Lohfink <clohfin...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> No tuning will eliminate gcs. >>>>>>> >>>>>>> 20-30 seconds is horrific and out of the ordinary. Most likely >>>>>>> implementing antipatterns and/or poorly configured. Sub 1s is realistic >>>>>>> but >>>>>>> with some workloads still may require some tuning to maintain. Some >>>>>>> workloads are very unfriendly to GCs though (ie heavy tombstones, very >>>>>>> wide >>>>>>> partitions). >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On Fri, Nov 25, 2016 at 3:25 PM, S Ahmed <sahmed1...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello! >>>>>>>> >>>>>>>> From what I understand java GC pauses are pretty much a fact of >>>>>>>> life, but you can tune the jvm to reduce the likelihood of the >>>>>>>> frequency >>>>>>>> and length of GC pauses. >>>>>>>> >>>>>>>> When using Cassandra, how frequent or long have these pauses known >>>>>>>> to be? Even with tuning, is it safe to assume they cannot be >>>>>>>> eliminated? >>>>>>>> >>>>>>>> Would a 20-30 second pause be something out of the ordinary? >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >> > > > -- > Benjamin Roth > Prokurist > > Jaumo GmbH · www.jaumo.com > Wehrstraße 46 · 73035 Göppingen · Germany > Phone +49 7161 304880-6 · Fax +49 7161 304880-1 > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer >
