Databases
StackOverflow2013
Postsdbo
POtcp or udp, another comparision
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POtcp or udp, another comparision
    primarykey
    data
    text
    <p>Consider a cache application with thousands of requests per second where the client asks for an object using an integer index and the server sends the object back to it. (Linux only)</p> <p>What would be faster for an UDP protocol:</p> <ul> <li>Send multiple replies in a single packet?</li> <li>Send a single reply in one packet?</li> </ul> <p>(applicable for both sides , server or client)</p> <p>Disadvantages:</p> <ul> <li><p>Multiple replies per packet:</p> <ul> <li>many memcpy()s will be needed to assemble packet with multiple replies. If a get() request returns to the client 16 byte objects, a single packet of 65535 bytes would have to memcpy() about 4000 objects before issuing sendto() system call. <em>memcpy() is costly</em></li> <li>An UDP packet of 65000 bytes will generate about 43 udp packet headers since the packet will be transmitted in fragmetns, due to 1500 default MTU size. <em>not a big overhead</em></li> </ul></li> <li>Single reply per packet: <ul> <li>every get() will result in 28 bytes of protocol overhead. For an object of 16 bytes this will be costly. The throughput of objects per second will be low and <em>network will be saturated with packets</em>. For example, sending 4000 objects will generate 4000 udp packet headers, condierably more than 43 headers with multiple replies. </li> <li>Also, too many sendto() syscalls will <em>increase CPU consumption</em> becase the kernel has to save CPU registers on each syscall.</li> </ul></li> </ul> <p>It appears that both methods have their disadvantages and it is not clear which solution will be better, however, the clock of gigabit ethernet runs at 1GHz while the processor is for example 3 GHz also the memory bus is much wider than the twisted pair of the ethernet interface. So, multiple replies per packet would be better choice since the extra memcpy()s will reduce network traffic, correct?</p> <p>Now, if we use TCP instead of UDP:</p> <ul> <li>Multiple replies per packet: <ul> <li>again, many memcpy()s will be needed to assemble the packet, which shouldnt be larger than 65535 and then it would be fragmented by the kernel to send it in packets of size of the MTU <em>not much difference as with UDP here</em></li> </ul></li> <li>Single reply per packet: <ul> <li>Since our 16 byte objects are distributed randomly in server's memory, we will have to issue a write() syscall per object, <em>the same number of syscalls as with udp</em> single request case.</li> <li>every get() will result in 52 bytes of overhead due to that TCP has larger header + we will have to another overhead of ACK packet which is abour 40 bytes. <em>even bigger network traffic</em></li> </ul></li> </ul> <p>Conclusion:</p> <ol> <li>For this particular application (sending simple data chunk to the client from an index given by the client) <em>TCP will not perform any better than UDP</em>. + consider that the implementation of TCP stack is much more complicated than UDP, more instructions are executed there. <strong>The whole point for making the protocol to run faster is to assembly UDP packets as large to the MTU as possible</strong>.</li> <li>The cost of adding another NIC to the system is lower than adding another CPU. It makes sense to go for lowering the number of memcpy()s but send a bunch of small UDP packets and pay extra for the overhead of each udp header on the network side (+ some little more overhead by doing many sendto() syscalls which i think will be lower than memcpy()'s overhead) because this way with one CPU could send requests over many NICs</li> </ol> <p>Will greatly appreciate your comments and your experiences on the choice of protocol.</p> <p>Note: lets set aside the reliability issues and assume our networks are error free, which is most of the time true if you wire them correctly, and if an error occurs it is certainly not the norm</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USNulik
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POtcp or udp, another comparision
      1. This table or related slice is empty.
      1. VTUpMod
    1. COMy approach to this would be to keep packets under the MTU and batch a certain number of results per packet along with identifying information, i.e. 2 of 10 or some other way to make sure you haven't lost anything. Remember that UDP permits lost packets and will not retry on its own, while TCP will attempt to resend packets that are not acknowledged. Judging by your reliability statement I'm thinking you control the network and aren't crossing any third-party/internet equipment?
      singulars
      1. POtcp or udp, another comparision
      1. USJamieSee
    2. COEven on a robust, internal network that may not have significant data "corruption" problems on UDP, it's not all that uncommon for packets to occasionally become reordered in UDP if there are multiple routes or multiple NICs on the sending or receiving end. Ultimately, is your protocol/application robust to packet loss, corruption, and reordering?
      singulars
      1. POtcp or udp, another comparision
      1. USutopianheaven
    3. COEven if networks are error free (hah!), switches, routers , network cards, operating systems will drop packets. It does not take that big a burst of UDP packets to fill up buffers and have packet drop as a result.
      singulars
      1. POtcp or udp, another comparision
      1. USnos
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload