If you're in trouble and cannot find an answer to a question which goes beyond Stack Overflow...
If you have a not-so-usual solution for your problems but need to justify it to your boss...
If you like to think on your own rather than blindly follow "common wisdom" and "profound truth"...
...then 'No Bugs' Hare on Soft.ware might be the right place for you.
Your mileage may vary. Batteries not included

Assorted Rants Tagged ‘Cache’, page 1:

OLTP DB Optimizations 102 –100% Coherent App-Level Cache for Single-writing-DB-connection

posted by

Quote: “with our app-level cache, we’re guaranteed to get exactly the same results as if we’d be querying the underlying database.”
Another Quote: “why settle for invalidation when we can modify cache accordingly, saving on the extra DB request when we’re dealing with the same USER again?”
[→]

#CPPCON2017. Day 2. Why Local Allocators are a Good Thing(tm) Performance-Wise, and Why I am Very Cautious about C++17 STL parallelized algos

posted by

At CPPCON2017 Day 2, two talks were of special interest to me. One was a 2-hour talk about Local Allocators – and another about C++17 STL parallelised algorithms. Local Allocators The talk on Local Allocator by John Lakos was brilliant both in terms of content and in terms of presentation (I wish I’d be able to speak […]

The Importance of Back-of-Envelope Estimates

posted by

Quote: “trying to optimize out a 3e-7 performance hit is very rarely worth the trouble.”
Another Quote: “With 4S/4U boxes having typical MTBFs of 3–5 years, the next question we should ask ourselves, is "Hey, will we really be able to write software which crashes much more rarely than that?"”
[→]

Scaling Stateful Objects

posted by

Quote: “it is DB which is usually The BottleneckTM – it means that we’re saving this enormous amount of load, exactly where it really matters.”
Another Quote: “as discussed above, the real-world task is always about scaling the whole system, including database; and in this regard Stateless-App-based systems exhibit significant problems.”
[→]

Gradual OLTP DB Development – from Zero to 10 Billion Transactions per Year and Beyond

posted by

Quote: “to make an efficient representation usable for OLAP – we need to modify our data on its way to OLAP replicas”
Another Quote: “Each of the DB Server Apps is a replica master, but all replica targets are within the same Replica DB”
[→]

Ultimate DB Heresy: Single Writing DB Connection. Part II. Gradual Scalability. All the way from no-scale to perfect-scale.

posted by

Quote: “And after this split of USERS table, the system has achieved perfectly linear scalability.”
Another Quote: “Start with a simple single-write-connection DB, with reporting running off the same DB”
[→]

Ultimate DB Heresy: Single Modifying DB Connection. Part I. Performance (Part II. Scalability to follow)

posted by

Quote: “Dealing with transaction isolation is very far from being a picnic”
Another Quote: “One of such real-world systems was consistently processing over 30M real-world write transactions/day over one single DB connection, supporting ~100K simultaneous players.”
[→]
Copyright © 2014-2016 ITHare.com