|
A jumbo ethernet frame can be 9000 bytes. The ethernet frame header
is at least 38 bytes, and the minimum TCP/IP header size is 40 bytes
or 0.78% of the jumbo frame combined. Gluster's RPC also adds a few
bytes (not sure how many and don't have time to test at the moment
but for the sake of argument we'll just say 20 bytes) but, all
together, it's about 99% efficient. If you write 20 bytes to a file
(for an extreme example) then you'll have your 20 bytes+RPC
header+TCP/IP header+ethernet header; 118 bytes in headers for 20
bytes of data. That header being 90% of the frame means that your
packet is only 10% efficient. That's per replica so if you have a
replica 3 that's three individual frames with 118 bytes of headers
each to write the same 20 bytes of data. Those go out to the three
servers and wait for their response. So you have a network round
trip + a tiny bit of latency for stacking the three frames in the
kernel + disk write latency. That's a lot of overhead and cannot
ever be as fast as writing to a local disk for any networked
storage. The question, however, is does it need to be? Do you care if a single thread is slower in a clustered environment than it would be on a local raid stack? In good clustered engineering your workload will be handled by multiple threads over a cluster of workers. Overall, you have more threads than you could have on a single machine. This allows servicing a greater overall workload than you could without a cluster. I refer to that as comparing apples to orchards (1). On 04/13/18 10:58, Anastasia Belyaeva
wrote:
|
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
