On Thu, May 18, 2006 at 10:09:58AM +0200, Boudewijn Visser wrote: [over djbdns dnscache]
Eerste voor de hand liggende optie is om die 200 wat groter te maken, naar 1000. Hij staat bij ons al zo hoog of zelfs hoger dan dat. Het probleem is hierbij dat er geen huishouding in het array gebeurt, dus hoe langer je de lijst maakt, hoe harder het CPU gebruik gaat stijgen, en het probleem wordt niet opgelost op een drukke resolver IMO. Bij 2000 worden bij hoge queryload (hoog is in mijn ogen >1kqps) veel queries tientallen milliseconden langer dan strict noodzakelijk, omdat alle operaties op inkomende en uitgaande queries dan lineair door die lijst moeten lopen en de complexiteit O(^2) maakt (1000qps * avg(2000)) is al gauw > 1M iteraties per seconde, terwijl dit heel prima ook O(1) kan en lineair groeit bij queryload in plaats van exponentieel. Kun je het hier mee eens zijn, denk je ?
Natuurlijk, maar uit je reply maakte ik op dat je nog op de default 200 zou zitten. En zeker, als je array groter wordt wil/moet je slimmer dan lineair zoeken, het is alleen meer implementatie werk dan simpelweg de limiet van 200 verhogen. Mijn natte vinger gok was (en is) dat voor orde 1000 qps , array van 1000 en een beetje stevige server lineair nog wel acceptabel is. En in elk geval de moeite van het proberen waard.
Je zou een recompile voor meer uitstaande queries als quick fix kunnen gebruiken. Thanks for the tip, maar dat gaat 'm niet worden vrees ik.
tsja, als je de simpele inkoppertjes al gehad hebt wordt het echt werk :-) Boudewijn