51–60 of 99 posts
Personal pet-peeve of mine. Using "TPS" or "Transactions/sec" to measure something that is in no way transactional. Maybe ops/sec, reads/sec, updates/sec, or something...
"A Cassandra compatible NoSQL column store, at 1MM transactions/sec per server." Personal pet-peeve of mine. Using "TPS" or "Transactions/sec" to measure something that is in no way transactional. Maybe ops/sec, reads/sec, updates/sec, or something...
Earlier quoted context omitted.
Agreed, but which architectural features are you referring to?
Over the last decade, the distributed system nature of modern server hardware internals has become painfully evident in how software architectures scale on a single machine. The traditional approaches -- multithreading, locking, lock-free structures, etc -- are all forms of coordination and agreement in a distributed system, with the attendant scalability problems if not used very carefully. At some point several yea…
Earlier quoted context omitted.
How does one bypass the kernel for network and disk IO? I've never heard of doing this before (e.g. IO is always a system call)
Oracle has long argued the value of bypassing the file system and associated kernel drivers with its raw devices and ASM. It'd be interesting to see such a thing land in other platforms.
Wait, did I read that right? the test was with (1) one server? What's the point of that? Smells like a cooked up test.
All the external facing things for scylla is the same as Cassandra. That includes all the ring stuff and all network protocols.
So you should expect similar cluster behavior.
Earlier quoted context omitted.
Over the last decade, the distributed system nature of modern server hardware internals has become painfully evident in how software architectures scale on a single machine. The traditional approaches -- multithreading, locking, lock-free structures, etc -- are all forms of coordination and agreement in a distributed system, with the attendant scalability problems if not used very carefully. At some point several yea…
How does one bypass the kernel for network and disk IO? I've never heard of doing this before (e.g. IO is always a system call)
Finally, back to sanity of great old-school products, like Informix, by dropping Java (the whole scam) for C++14 and by paying attention to details of an underlying OS (again). Same trend, by the way, is in Android development.
10x speedup (same algorithms, same architecture) replacing Java with C++ is not possible (~2x at max). One of the latest benchmarks I've seen is "Comparison of Programming Languages in Economics" [1] for code without any IO just number crunching, has a 1.91 to 2.69 speedup of using C++ compared to Java. So any code involving IO is going to be slower. Replacing bad Java code with excellent machine aligned C++ a 10x sp…
Java has a ton of overhead that C++ doesn't. Each object has metadata which results in more "cold data" in the cache. Each object is a heap allocation (unless you're lucky enough to hit the escape analysis optimization), which again leads to less cache locality because things are distributed around memory. Then there's the garbage collector. Then bounds checking.
Earlier quoted context omitted.
Except that problem has been largely addressed now.
I really really really want to see Aphyr attack the patched version to see if he thinks the fix actually worked.