3 ms·
I see, so in your example service B is modeling a cache miss. My initial reaction was like, service B is "failing" so wouldn't the fault tolerance and autoscal
by abalone 12y ago
I see, so in your example service B is modeling a cache miss.
My initial reaction was like, service B is "failing" so wouldn't the fault tolerance and autoscaling you ought to have in place be good enough to deal? But a write-through cache is a good example where there can be a relatively massive disparity in latencies depending on whether it's a hit or miss, and thus a swarm of misses could tie up the server's connections. So getting an extra ~10X connections to work with makes a big difference.
I guess my next thought would be, how broadly applicable are those service characteristics? And is it worth the "risk" of stitching in a library that does bytecode manipulation and whatnot as a general practice, or should I use it in a more targeted fashion?
Again just thinking out loud.. I'm very impressed with the work. Kudos for a library that minimizes the complexity of async programming.
- pron 12y agoActually, service B is modeling a failure. What I meant in my previous comment was that adding more machines for scaling is not only more expensive, but can add significant latencies if those machines are using a distributed cache (as each would invalidate the other's caches, creating more misses). It's always preferable to utilize fewer machines better. I would say that the risk Quasar brings is no different from any 1 year old library. It's young, so test it well and introduce it carefully gradually to production. The bytecode manipulation Quasar performs is vastly simpler than, say, JRebel. Quasar does not change object layouts or any such thing. It simply injects code into suspendable methods to copy local variables into an array and back.