Date: Wed, 30 Dec 1998 19:25:13 -0500 From: "Gary Palmer" <gpalmer@FreeBSD.ORG> To: "Steven P. Donegan" <donegan@quick.net> Cc: Mike Smith <mike@smith.net.au>, Josh Tiefenbach <josh@ican.net>, The Hermit Hacker <scrappy@hub.org>, freebsd-current@FreeBSD.ORG Subject: Re: NOW/MOSIX/Beowulf Message-ID: <28835.915063913@gjp.erols.com> In-Reply-To: Your message of "Wed, 30 Dec 1998 14:13:20 PST." <Pine.BSI.3.91.981230141010.23928C-100000@oldnews.quick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Steven P. Donegan" wrote in message ID <Pine.BSI.3.91.981230141010.23928C-100000@oldnews.quick.net>: > I 'vampired' my corporate LDAP directory (roughly 15k entries) and > populated a FreeBSD and Netscape system with it (FreeBSD was the ldap in > the ports directory). Both systems were basically identical as far as > hardware goes. The FreeBSD response to queries was roughly twice as fast > as the Netscape under NT. Since the database was very small (5 meg or so) > I would see no reason why this couldn't scale indefinitely... (round > robin DNS or Cisco load director etc.). In my application (ISP), the point of any network based information system (i.e. LDAP) is to provide local caches of information on the machines which need them, with near-real-time updates, so users can get near-instant password changes across 20+ machines, new accounts created before they hang up, etc. My interpretation, and I'm sorry if I'm a bit blunt, of what you're suggesting is more akin to redefining the problem and then throwing hardware at it to scale it horizontally. Not making the application or the software faster & more reliable, but rather just plain throwing hardware at it. Now, you have to understand that my opinions of LDAP aren't for everybody. One of the speakers at LISA earlier this month was very eloquent about the benefits of LDAP in a MIS-type environment, where you are easily centralizing configuration management. My observations come from the standpoint of an ISP, where having local information (preferably read by the querying application straight out of memory) is much preferable to having to traverse the network stack (and possibly a physical network also) a minimum of two times to get the information they are after. Now LDAP looks on the outside very attractive. A network based query API which is meant to have servers which are tuned for reads, but can handle the occasional update. You can toss any data you want into it. It handles replication between servers, so no more custom scripts to handle distribution of locally required information. But, as Josh pointed out, there are downsides. In his case, the schema his legacy system forced him into required that there be multiple LDAP queries to retrieve a single piece of data. This greately increases the resources required to run a local LDAP replica (lets face it, most of the free LDAP servers use DBM as a backend, and I believe Netscapes directory server does also, which isn't the fastest product on the planet) So I guess it all depends what you want. For what this thread started on (a highly scalable mail delivery/processing system), I think with a bit of eblow grease and some understand of the problem, a faster solution which is more tailored to the query needs of your environment, without breaking the bank on adding hardware to support LDAP, is attainable. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28835.915063913>