[ga] Re: No more FUD -- what is the current size of the .com database?
Stephane Bortzmeyer wrote: The DNS part of the registry is the easiest one. Many root name servers run on regular PC. But the problem is the database: it has to accept a *lot* of updates (in their bid for ".net", Verisign said their system handled 14,000 *updates* per *second*). And a lot more of queries (through whois or RRP). Well, even if we assume that the *average* rate is half of that 14,000, i.e, 7,000 a second, that turns into about 605,000,000 update/day or about 220,752,000,000 per year. Or about 3700 updates per year for each of the 60,000,000 names that .com will have soon. Another way to estimate is to assume that each of the 60,000,000 names undergoes one update transaction per year - yes that is probably a tad low, but we can multiply the result when I'm done - That works out to roughly two transactions a second - and 2 is much less than 14000. And if I'm off in my estimates of transactions per name per year by say a factor of 100, that still means we're talking only 200 transactions/second. So, I don't really believe the 14,000/second figure is accurate - that is unless one counts the polling rates from registrars and the thrashing of names under the 5-day graces, but I hardly consider that a necessary part of the system. They are relics of the system that ICANN has created and imposed. But they are not necessary - for example, in my .ewe plan there would be no polling for drops because there are no drops. Now, I once worked doing networks and running several systems at a place that had a real transaction rate - one of the largest banks in the US, the daily cash flow was measured in billions upon billions of dollars - And yes there was some serious iron and facilities and security procedures that kinda resembled Fort Knox.) So I do understand the issues, albeit my contact is with that kind of processing is years out of date. For purposes of comparison: According to the Visa credit card folks, their systems can handle 6,300 transactions/second, worldwide. It is hard to believe that the .com transaction rate - real transaction rate for .com as measured by transactions that result in the transfer of money - is on the same order of magnitude as the entire credit card transaction rate for the entire world. But from the point of view of ICANN and internet stability - and as usual I measure that stability in terms of the ability of DNS to turn DNS query packets into DNS reply packets - the speed and even the availability of the front-office name registration system is rather irrelevant. By this I mean, that if Verisign's registration systems were to wobble it would not really impact internet users very much; most wouldn't even notice. Registrars would be going nutz, and speculators would be going nutz. But for normal folks, waiting an extra day to get a domain name while the system is repaired would not be a catastrophe. And we ought not to forget that Verisign has had the benefit of 11 years of monopoly revenue from .com to pay for its systems. As for competing root operators - no root server is hit with anything like the load hit by .com. Operating a root server is a small thing compared to serving up .com. As for competing TLDs - there is no reason why ICANN should require a baby .web, for example, to come online equipped as if it were .com. As long as its name servers are scaled to the query rate, and as long as their front office systems are fast and reliable enough to keep their customers happy, then it's really none of our business to require overcapacity. --karl--
|