Thank you so much!<br>
<br>
Liqun<br><br><div><span class="gmail_quote">On 11/27/07, <b class="gmail_sendername">Michael Tokarev</b> <<a href="mailto:mjt@corpit.ru">mjt@corpit.ru</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Liqun Du wrote:<br>> Thanks for the help. It works now. I have few load/scalability<br>> questions. If we have several millions of IP in the BL, should we use<br>> multiple rbldnsd (with multiple zones)? How big the list it can load
<br>> without having a performance issue?<br><br>The answer depends on your setup.<br><br>The most important thing is the type of dataset you'll use.<br>For a simple but large list, use ip4tset (not ip4set) - it<br>
requires only 4 bytes per IP address (as opposed to ip4set<br>which requires 8 bytes minimum per entry plus whatever<br>text you assotiate with listings).<br><br>It will spend some time to reload a list, the more time the
<br>greather the list is. Just try it out and see if the performance<br>is sufficient for you (hardware etc is different everywhere).<br>Try with -f switch (background reloads) - it requires 2x amount<br>of memory during reloads, but it continues answering queries
<br>during that time.<br><br>If you want to store highly dynamic data, there are some ways<br>to minimize number of full reloads. For example, DSBL.org<br>currently lists about 13M IP addresses, yet new listings are<br>propagated to all the official secondaries in 1..2 minutes -
<br>obviously such a small time window isn't sufficient to do<br>a full transfer of the complete file and to reload it.<br><br>Running several rbldnsds on the same machine for scalability<br>reasons seems to be not necessary. You can divide your data
<br>into smaller chunks - for example, more frequently changing<br>data separately from more static data, -- again, to minimize<br>reload time. Running multiple machines with the same rbldnsd<br>setup may be good for reliability - if for whatever reason one
<br>machine stops or dies...<br><br>Again from DSBL.org data and usage, a 600MHz PIII-Celeron<br>machine (which is a joke by current standards) can answer<br>more than 10k queries per second (with that 13M entries<br>list plus several more public blocklists).
<br><br>So the main recommendation is - just try it out and see.<br>If something goes slow, there are ways to optimize it.<br><br>/mjt<br>_______________________________________________<br>rbldnsd mailing list<br><a href="mailto:rbldnsd@corpit.ru">
rbldnsd@corpit.ru</a><br><a href="http://www.corpit.ru/mailman/listinfo/rbldnsd">http://www.corpit.ru/mailman/listinfo/rbldnsd</a><br></blockquote></div><br>