Re: [PATCH] dnscache: merge similar outgoing udp packets

Mark Johnson <[email protected]>
Newsgroups gmane.network.djbdns
Message-ID <[email protected]>
2009/4/23 Krzysztof Gajdemski <[email protected]>:
> 21.04.2009, 16:10:41, Jeff King wrote:
>> Thanks. The list has been silent on success reports, so perhaps nobody
>> is actually using it. I've been running it for a few weeks now without
>> incident, but only on a lightly loaded server (and only on dnscache --
>> the changes shouldn't affect other programs, but I haven't tested it
>> extensively).
>
> I've just tested Your patch in rather loaded dnscache cluster. Patched
> dnscache was installed on only one server within the cluster so
> performance between patched and unpatched version could be easily
> compared. During a period of testing (about one hour) I had no visible
> name resolving problems. Query merging engine also worked just fine.
> Unfortunately, there was a serious performance issue.
>
> Hardware and software configuration of each machine was identical (quite
> old 2 x Xeon 3GHz IBM x336 server), on each host two instances of
> dnscache were run. During the tests single dnscache instance processed
> above 1000 queries per second (a rather low value for my system - it
> was early morning). Average usage of each CPU on unpatched servers was
> about 30%, but on the patched server with MERGEQUERIES variable set, it
> raised to 90% - 95% (the process consuming almost all CPU power was of
> course dnscache). After removing the MERGEQUERIES variable, CPU usage
> lowered to a normal level (ca. 30%), so I think the problem lays
> somewhere in query merging code.

Is the issue just the CPU usage?  Was the patched server able to keep
up with the unpatched servers in terms of queries per second?  With
the CPU usage as high as you observed, I'd suspect it wasn't.  It
would be good to know the qps limit with query merging enabled.  Is
the 1000 qps number you mentioned for the unpatched servers, patched
servers, or both?

> Your patch was tested against lightly modified dnscache. The
> modifications include:
>
> - SOA caching patch;
> - Large CACHESIZE patch. In fact, CACHESIZE was set to 2000000000 for
>  each dnscache instance (but no swapping, memory shortage or IO issues).
>
> All above was tested under Debian GNU/Linux with 2.4 kernel on the i386
> architecture. If you have any additional questions, don't hesitate to
> ask.

What was MAXUDP/MAXTCP set to?  Default of 200?  Or some other setting?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.