[Pdns-users] Re: Auth. server has poor TCP performance.

[Augie Schwer]

http://wiki.powerdns.com/cgi-bin/trac.fcgi/ticket/177

Moving the recursive call outside of the lock block seems to fix this
problem; patch below, I've got this patch testing on a few servers and
so far no problems:

Index: pdns/tcpreceiver.cc
===================================================================
--- pdns/tcpreceiver.cc (revision 1141)
+++ pdns/tcpreceiver.cc (working copy)
@@ -241,6 +241,7 @@
     DLOG(L<<"TCP Connection accepted on fd "<<fd<<endl);

     for(;;) {
+      bool shouldRecurse;
       ComboAddress remote;
       socklen_t remotelen=sizeof(remote);
       if(getpeername(fd, (struct sockaddr *)&remote, &remotelen) < 0) {
@@ -292,16 +293,16 @@
          L<<Logger::Error<<"TCP server is without backend
connections, launching"<<endl;
          s_P=new PacketHandler;
        }
-       bool shouldRecurse;

        reply=shared_ptr<DNSPacket>(s_P->questionOrRecurse(packet.get(),
&shouldRecurse)); // we really need to ask the backend :-)

-       if(shouldRecurse) {
-         proxyQuestion(packet);
-         continue;
-       }
       }

+      if(shouldRecurse) {
+       proxyQuestion(packet);
+       continue;
+      }
+
       if(!reply)  // unable to write an answer?
        break;



On Wed, Feb 13, 2008 at 12:56 PM, Augie Schwer <augie.schwer at gmail.com> wrote:
> We have mixed use recursive servers that have both the auth. server
>  and the pdns recursive server; the auth. server sees the client query
>  first and hands it to the recursor if it doesn't have the answer; it's
>  in this exchange that we see the problem.
>
>  it seems that the TCP receiver can only handle one request at a time.
>
>  The problem we've seen is if one request takes a long time to get an
>  answer (like if the recursor takes a while to get back because the
>  remote name server is slow or doesn't answer), then the other requests
>  pile up behind it, get enough of these and the receiver stops
>  accepting requests all together.
>
>  It's like the single TCP thread locks a global semaphore and all the
>  other threads just wait for it to be done. Shouldn't the TCP threads
>  be able to handle multiple simultaneous connections?
>
>  We see this mostly with Microsoft mail servers who prefer TCP for everything.
>
>  Any thoughts?
>
>
>  --
>  Augie Schwer    -    Augie at Schwer.us    -    http://schwer.us
>  Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072
>



-- 
Augie Schwer - Augie at Schwer.us - http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072