BIND 10 #245: Meaure performance of various "receiptionist" designs

[BIND 10 Development]

#245: Meaure performance of various "receiptionist" designs
---------------------------+------------------------------------------------
      Reporter:  shane     |        Owner:  stephen                    
          Type:  task      |       Status:  new                        
      Priority:  major     |    Milestone:  06. 4th Incremental Release
     Component:  recurser  |   Resolution:                             
      Keywords:            |    Sensitive:  0                          
Estimatedhours:            |        Hours:                             
      Billable:  1         |   Totalhours:                             
      Internal:  0         |  
---------------------------+------------------------------------------------

Comment(by dhankins):

 How the receiving end of message queues wake up is critical.  Since we are
 using a message queue library, some inspection may be required.

 In my earlier experiments with a shared memory ring buffer implementation,
 the only way I discovered I could hold the receiver asleep and wake up (as
 opposed to being awake all the time polling the ring buffer for contents)
 was on a "negative lock" using a semaphore.  The reader locks a semaphore
 if the ring buffer is empty, possibly going to sleep; the writer unlocks
 the semaphore when data is put in the ring buffer, causing the reader to
 wake up more or less instantaneously.

 The other solutions to sleep the reader which I attempted all resulted in
 the the queue being over-run by burst traffic from the UDP socket; the
 ring buffer would quickly be completely filled over the smallest periods
 of sleep.  Except on our Solaris lab boxes where for some reason UDP read
 performance was horrendous, so the ring buffer mechanic showed no
 difficulty in exceeding UDP read performance.

 Note that such synchronous design may not be practical particularly in
 recursive nameserver design, where the process likely will need to handle
 retransmission behaviour, and will probably be governing other UDP sockets
 for its own query/replies.  A message queue implementation that is
 compatible with select(2) like the POSIX message queue or similar may also
 be worth investigation.

 However in authoritative DNS and DDNS (and therefore most DHCP use cases)
 where typically the work is to reply to individual messages, this issue
 with synchronous design isn't as obvious (may not be an issue).

 HTH.

-- 
Ticket URL: <http://bind10.isc.org/ticket/245#comment:3>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development