Re: [Sks-devel] 3 million keys & and community help requested

[Robert J. Hansen]

On 11/2/11 3:08 PM, John Clizbe wrote:
> One would need to ask Yaron to verify why BDB.

A former co-worker of mine used to play college football.  One of his
engineering maxims came from his time on the gridiron: "if the instant
replay doesn't make the right call clearly obvious after three
watchings, there is no wrong call."

There's a lot of wisdom there.  The question may not be why Berkeley was
chosen, nor even why the others were not chosen.  The question may be
instead, is there anything clearly and obviously better than Berkeley DB?

My position is 'no,' and for that reason I think asking for
justification for Berkeley DB is kind of pointless.  If there's nothing
obviously better, then why are we interested in his decisionmaking process?

> Indeed, IME the single worst bottleneck in SKS is the initial loading
> of the database from a keydump. One of my development boxes actively
> syncs with several SKS peers. It runs quite well on a 500MHz Sun
> Blade 100 with ATA/33 disks and 2GB of RAM. [Takes a while to load
> though :-(  ]
> 
> Next up is WAN bandwidth, but that's usually only an issue when a
> server initially peers or comes back online after a long absence, and
> only the first recon peer will see the slow down.

Ack.  The bootstrapping process is the most difficult part.  After that,
running a keyserver is a remarkably low-load process.  When I run top I
invariably discover that it requires more CPU and memory than sks!

address@hidden ~]$ uptime
 15:17:40 up 52 days, 22:10,  3 users,  load average: 0.14, 0.05, 0.06