On Sat, Sep 8, 2012 at 12:18 PM, Sebastian Cohnen <sebastian.coh...@gmail.com> wrote: > Sean, > > how do you explain these rather huge improvements Amazon presents in their > Dynamo paper? >
My point was mainly that the performance benefits vs. complexity overhead you would get from client-side routing is sometimes not as great as simply getting better hardware or more nodes. That is a big, complex feature to implement on both sides of the connection. Clearly, doing a local disk I/O to fetch the key, and then waiting for only one replica from the network before replying is going to be more efficient than going to the remote nodes for both replicas needed to meet the default quorum. Additionally, requesting fewer remote replicas would reduce the effects of TCP incast, should you be under high load. On the other hand, if the value is not in the local disk cache or a buffer maintained by the storage engine, you might very well be seek-bound (in some engines multiple seeks), making the network overhead negligible in comparison. For example, we have seen several Riak users on AWS become bound by latency to the EBS volume (even when in RAID), while the network is comparatively idle. Most people also store small values in Riak, meaning a response from or request to a replica will often fit inside a single MTU. This is certainly something we want to do in the future, but without it being the greatest bottleneck, we'll focus our performance improvements elsewhere in the meantime. There are still many gains to be made in our storage engines and other core components. -- Sean Cribbs <s...@basho.com> Software Engineer Basho Technologies, Inc. http://basho.com/ _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
