10 April 2007 - 21:14rabid ramblings of a deranged hacker
The past week has shown me a few things I hadn't realized before. E.g., there's more than a couple handfuls of people interested in directory technology these days, but not a lot of them are any good at it. The Fedora project bills itself as "powerful open source ldap." The OpenDS project has a stated goal "to provide high performance." The ApacheDS project states their "vision is to build an enterprise directory server platform and its components."
Have some guts. If your aim is to be the best and fastest in the world, say so. But understand what that really means...
Directory software is not like a word processor. It's not about fancy menus and pretty icons. Infrastructure is ideally meant to be indestructible and invisible. In network terms, it should be like an optic fiber - flexible, transparent, and passing data at blindingly fast speeds. It should work so smoothly and quickly that users don't ever even know that it's there.
LDAP's popularity has surged and waned over the years, and it's on the upswing again as the latest incarnation of identity management buzzwords latches onto it again. Ultimately this surge is a good thing; encouraging application developers to talk a standard protocol to access all the information they need is a big win for software manageability, portability, interoperability, etc. But before you go layering all of these other systems on top, you need to have a solid foundation. You need an infrastructure like titanium - strong, lightweight, and resilient. It needs to be so utterly reliable and so absolutely fast that people can just take it completely for granted, and just use it without worrying about it.
In recent years "software optimization" has almost become a dirty word. You're always cautioned against premature optimization, you're advised to "know when enough is enough" and stop. Unfortunately it seems like folks are so afraid of optimizing too soon that they put it off forever. One thing you have to realize, when you're building infrastructure or development tools - there is no such thing as "fast enough." Because, just like disk drives where file sizes have continued to grow to occupy all available capacity, users will always find ways to absorb every bit of bandwidth available, every compute cycle, and every ounce of performance. If you're not always looking for ways to improve, looking for perfection, then you're wasting your time. Worse though - you're wasting users' time, and energy.
People are slowly catching on. In this day and age of data centers running at peak capacity, with no more space or electrical budgets to expand, it's becoming obvious that by and large, computing efficiency today isn't what it should be. I think a great deal of that has to do with the education system that has produced the most recent crop of software professionals. People are trained to use very high level languages, which allows them to directly implement software designs comprising many levels of abstraction layers, without any particular regard to their underlying implementation. If they're ever even taught anything about algorithmic efficiency, it's only in very abstract terms, using simulations that have no connection to reality. The result is a lot of bloated software that works well enough on the test bench with one or two test cases, but doesn't run worth a damn on anything else.
When I was back at the University of Michigan Computing Center, my friends and I used to joke about "shaving nanojiffies" - we'd tease each other about that as we talked about our latest neat hack in whatever we were working on. That was on an IBM mainframe, where our users were all billed for every microsecond of CPU time they used. The fact was, shaving cycles mattered, and though we joked about it, it was still something we spent time thinking about. It had real consequences, that everyone felt. Sometimes I think programmers are too far from their user communities these days; they forget that even with free software, the product of their labor has real costs.
Most of us no longer live in a world of timesharing with billing per compute cycle, but still compute cycles are not free - they have a real cost in time and energy. AMD and Intel are on a "green computing" kick these days, but hardware can only do so much, software must also do its part.
When you kick a product out into the world that runs 3-4 times more slowly than it should, you're implicitly stating that you have no regard for your users, no respect for their time, and no concern for their welfare. When you have the audacity to then call your stuff "the best product on the market" you're just flat out lying.
Marty tells me there's very few people in the world as obsessive as I am. Sometimes I find that hard to understand. "If you're going to do something do it right" - why would you ever waste your time doing anything else? Life is short, if you're not doing something you excel at right now, why the heck are you doing it at all? Find the things you are good at and love to do, and nothing else matters. Be the best. "Do, or do not - there is no try."
Some folks attribute the success of the open source phenomenon to the quality of software you get from "many eyes." I think that's heavily overrated. I think great software projects get that way because somebody had an idea and pursued it obsessively, and took great care in shaping it and maintaining it. The vast majority of the "many eyes" are just too far removed from the original vision to really grok it. Only a handful of people ever really make the difference.
That touches on one of my other pet peeves - the whole notion of intellectual property, as if the output of a creative mind was a tangible commodity. The only thing important in intellectual property is the *intellect*. Creative people are what matter, they're where the real value resides. Take the writings of Stephen Hawking, print them out on giant billboards 30 feet high and you haven't enhanced their value. Line people up to read them, and for the most part you still haven't increased their value. It's not the output that matters, it's the intellect that can comprehend the output and extend it and manipulate it that matters. Software has no intrinsic value. Without the right people, a piece of software is just another random collection of electrons.
This world we live in has a lot of problems. We try to make things better, each in our own way. For me, part of that is making software better. If that's your passion too, if you want to work on the best directory software in the world and make it even better, then you should be working with us on OpenLDAP. If you don't care about being the best, or if you feel that re-inventing the wheel will be more fun, well, I guess that's your personal choice. But again, life is short - why waste your time working on something that is not and never will be the best? Why would you waste your users' time? And even if you're brazen enough not to care about your users, why would they want to run your stuff, knowing that you're only delivering them a tiny fraction of the performance their hardware is capable of, only a fraction of the throughput they paid for?
17 comments:
Dear Deranged Hacker,
I’m a little bit puzzled about your intdocution. You stated that we (apacheDS talking here) aren’t focusing on performance, as if it was the only valid criteria. Well, we are focusing on this one, plus some others you might not be interested in (ignoring what users are also asking for is your buziness, not mine however). We do want to have the fastest server on earth, the more reliable, and the most easy to use. The point is that it’s not something you can achieve in a few days, nor months. ApacheDS 1.0 has been released back on october, 2005. OpenLdap is present since 1998. Almost 10 years. We have just delivered a 1.5 versions, with performance twice better than the 1.0. I would say we was 4 times slower than OpenLdap back in October, and now, let’s say it’s only 2 times slower. Not too bad. But we have some margin !
If you think about it as a pure speed competition, then be sure we will compete. We do have some guts.
Is it important ? For both product, yes. For us, this is challenging. And we like challenges. For you, it’s interesting to feel like someone is chasing you, even if we are far away (not so much …), because you will have to move forward.
I won’t comment the rest of your post (I mostly agreed with it), just one point : I was used to count processor cycles when having fun with Z80, 6502 and other processors, back in 1980. It was great fun. World has just changed a little bit since then. When it comes to a Ldap server, saving CPU cycles is just one part of the equation when you know that disk access is around 1000 times more costly, and that network latency will be the bottleneck whatever your server speed is. Maybe you should consider those elements you seems to have neglected…
@Emmanuel Lecharny:
Apache DS is only two times slower? Our benchmarking tests have showing repeatedly that Apache DS is much worse off than only two times slower, even with the 1.5 release. I’ve offered previously to help you configure OpenLDAP for proper performance testing, I’ve yet to see you take me up on that. When you are ready to do so, please let me know. The results I have seen you post to the Apache DS list also did not come from a distributed client testing methodology, such as slamd, but from a local client testing methodology (along the lines of the old directoryMark) which unfortunately can never give an accurate representation of how well an LDAP server really performs, as there is too much competition for resources between the server and client, and no ability to act as true clients from multiple sources.
As for disk acccess, network latency, etc—OpenLDAP, when properly configured, avoids using the disk as much as possible. And all servers will hit the same issues around network latency, so tests performed on the same sets of servers in the same environment are valid across the different types of directory servers in showing how they perform, since the network is the same. I suppose we could use the slamd stats trackers to monitor disk access across the various directory server products, but all that will effect, in the end, is their ability to serve requests—which will show up in the results generated by benchmarking.
—Quanah
@Emmanuel Lecharny:
Certainly speed is not the only valid criteria. Correctness always comes first. It can be easily demonstrated that offerings like Sun/FDS/RHDS fail on that score as well – ignoring schema, accepting and processing invalid BER messages, etc. But this wasn’t a comprehensive critique – there’s plenty wrong with those other codebases, but even a comparative analysis has to start somewhere.
The relative age of the code is interesting. Technically the OpenLDAP code includes the original UMich code, so the overall age is much greater. (And that heritage is present in Sun/FDS/RHDS as well.) But none of the original UMich authors were paying attention to efficiency either, so that “maturity” is more a burden than a benefit. The ApacheDS code was born in 2002; I would have expected people starting so much later to have learned from the mistakes made by those who have gone before. By 2002 I had sped OpenLDAP up by more than a factor of 200 (in some tests) compared to the OpenLDAP 2.0 code released in 2000.
Like Alex Karasulu, I looked at the OpenLDAP code in 2000-2001 and saw that it was brittle, lacking in various areas, etc. But unlike Alex, I didn’t blame the problems on the fact the code is written in C. The problems were from the C code being poorly written, sure, but fixing the code makes more sense than dropping it and starting over in an even less efficient environment.
I guess I have the same thing to say to you as I said to Pete Rowley – the fact that OpenLDAP has come so far in the past 5-6 years speaks volumes about our Project and people, especially compared to the (lack of) progress anyone else has made in the same span of time. And yes – it’s because of the people, not money. Sun/Netscape/RedHat have all spent many orders of magnitude more money on their stuff than anyone has ever spent on OpenLDAP.
Not sure what your point about CPU cycles proves. Eventually optimization becomes a tradeoff of space vs time, yes. You’re nowhere near that yet; ApacheDS requires the most memory and still runs slowest of all the tested packages. Meanwhile OpenLDAP is both more memory and CPU efficient than any other directory software, closed or open source. The fact is that because OpenLDAP runs at faster than wire speed, you only have to consider network latency; it doesn’t introduce any other bottlenecks. I haven’t neglected the other parts of the equation, I just took care of them so long ago it’s no longer worth thinking about.
DISCLAIMER: My opinions here are mine solely and are not the opinions of the ASF, it’s membership or that of the individuals involved with the Apache Directory Project.
=============
There’s a lot of FUD and bashing coming from these posts. I’m disappointed that the various LDAP communities out there would rather slam each other like this than work together to better the protocol and LDAP’s standing. I’m even more disappointed that this is taking place between people open source communities but I guess commercialization with Symas is driving many of these low comments. Where is the mutual respect out there? Why are people so threatened?
One of the major reasons why I started the Apache Directory project was to attempt to build a platform for experimenting with ways to better the protocol. Specifically I wanted to introduce rich constructs that makes using this integration tier technology more useful and attractive: I wanted to increase the uptake of LDAP by the enterprise. Many people often give up on using LDAP because the concepts are difficult to grasp and the proper constructs are not available for easily managing data. I see many abandoning LDAP to fall back to using an RDBMS because of their own lack of understanding or due to a greater comfort level with using a database. This is one of the biggest factors leading to the slew of integration problems plaguing our industry today: many don’t realize the directory will help ameliorate these problems if not solve many of them. LDAP as it stands has many areas for improvement and Apache Directory is something I wanted to help catalyze that evolution.
I did not start this project to insult or undermine the OpenLDAP community or any other open or commercial offshoot. Nor was my aim to compete with others over performance. Performance is something we have yet to seriously confront as we work more today to devise an architecture that will be flexible enough to support these ideas. The extent of our performance tuning to date has been minimal. We have merely fixed obvious issues that were low hanging fruit. Until we stabilize the architecture we feel optimization is moot. As the architecture shifts old bottlenecks will disappear as new ones are introduced. So we’re not trying to sell our selves based on speed just yet although if you properly tune ApacheDS it’s not that far from other servers. This I know is debatable but who knows if anyone is properly tuning all servers in their performance tests. People can try the options for now and decide. I’m not going to loose sleep over the use of other servers over ApacheDS.
Getting back to our intentions: We want other communities to consider the possibilities and evolve with us to make LDAP more prevalent and easier to use. We want LDAP to succeed, not necessarily ApacheDS or other incarnations based on it. Our present focus is on building a solid community while stabilizing an architecture that will support these delicious new features while minimizing complexity so the code does not get brittle. However I assure you that the time for performance tuning will come and our flexibility and lack of overhead in devising more sophisticated algorithms to deal with optimizations will give us a far greater advantage. Although this is a theory at this point you better believe that I will put it to the test. At that point I’ll be ready to talk about performance metrics. I don’t think we’re too far out from that either.
Clearly there are several aspects to what makes one server more advantageous over another under certain circumstances. You cannot please everyone all the time since requirements and environments vary without complete alignment with the capabilities of any one implementation. Different servers are better at different things. There rarely is a silver bullet out there for every situation.
It’s surprising how such intelligent people would rather forgo their reason and violate these fundamentals they clearly understand to slam another effort which may threaten them. This is a clear example of fear getting in the way of reason.
=============
As for the author of this blog entry …
=============
You’re a piece of work. You talk a big talk about your glorious computing experience in the old days. I guess this should make us feel like you’re the man so you can bash with credibility. However your nothing but a coward. You’re trying to compare an implementation based on decades of evolution to one that’s only hit the block a few years ago. Why are you trying to kick ApacheDS in the nuts so hard before it’s had a chance to mature? Is there something about it that threatens you? I think it’s crusty people like yourself that have kept LDAP so damn archaic and suppressed while worrying about the penis size of the man in the next urinal. Confident people don’t need to put others down to feel secure.
=============
As for you Quanah …
=============
You should make a sincere effort to join our community to foster some good will between all LDAP efforts and help advance LDAP. If all you’re going to do is act petty and feed this Symas propaganda with your ApacheDS back stabbing then you’re better off hitting the road. We’ve sincerely welcomed you as we do everyone … don’t try our patience by taking advantage of that.
@akarasulu:
Alex—I fail to see where I was “back stabbing” ApacheDS. I simply noted that I had offered to help Emmanuel in configuring OpenLDAP for performance, just as I in the past have asked the Apache DS project for tips on configuring it for performance, and that the results that he generated were not substantiated by actual distributed tests where things are properly configured. I still would like, very much, to see a centralized benchmarking environment open to Fedora DS, Apache DS, OpenDirectory, and OpenLDAP. I think that all parties involved could find things of use to learn.
—Quanah
Wow, quite a set of threads. I think everybody makes some good points. Here are my 2 cents:
Performance – Performance is very important, but not necessarily the most important thing. How the directory is used will also effect performance. People don’t generally go directly to the directory, but access an application that in turn accesses the directory. So if a directory can support 1,000 ops/second but the application can only login 300 users in that second and during that login process takes a .5 second then adding an additional 5-10 milliseconds at the directory level isn’t going to have a noticeable lag at the application level.
Java “Superiority” – There are fewer and fewer people in the “enterprise” that have C/C++ experience, but there is an increasing number of people with Java/.NET experience. If a customization needs to occur then if something is written in java and its hooks are java then you can make the argument that java based infrastructure is easier to customize and hence easier to deploy. There are (at least) three problems with this argument.
The first is that with directories this hasn’t really been a big deal. Directory data is generally fairly static and is often the “view” of some authoritative sources. If it’s the “view”, from a data integrity stand point its common not to change the directory directly at all.
The second is that the applications that interact with a directory for the most part know how to search and bind. Databases are often built for a specific application where as directories are more general infrastructure. This means you’ll be hard pressed to find an off the shelf application that can utilize a custom extended operation or control without customization.
The third problem with this argument is that because the directory is often so important, custom code (which could crash) could take out all applications that require it. To minimize this risk the custom logic is either externalized into the application or into an integration tool like a virtual directory.
The moral of the story is that the product used should be based on requirements. Some directories provide more features or other features. One directory may be faster with fewer users while others may scale better. It’s really which product conforms to the user requirements.
Finally, (warning: insane capitalist rant coming) competition is a good thing. I’m sure OpenLDAP, ApacheDS, OpenDS & FedoraDS will all have something to offer and so will push both each other and commercial vendors to improve their products.
OK, a but more then 2 cents….
@Marc Boorshtein:
Marc, thanks for checking in. No arguments. You make many excellent points with which I can only heartily agree.
On the whole Java/C#/YadaYada point, access to the directory from Java, Perl, PhP, etc. is easy and should be easy. The interfaces to the LDAP protocol from any and all application languages need to be easy for developers to use and should give them all the services the Directory can offer. We are all for supporting any and all application regimes.
Any remarks about performance and Java/C#(.NET)/etc. have to do with it as a language for high-volume systems software. The move from C++ to Java/C#/etc. is probably good for the “Enterprise” level developer but is not, necessarily, and in our opinion, for the developer of these utility layers that the “enterprise applications” rest on. Again, we gladly let the code talk and if we’re wrong, one of a couple of projects will prove it so.
We do compete in environments where performance and throughput on particular machine models is important. In those environments, the highest performance or best throughput is important and we naturally strive to deliver that. One very clear point of belief is that efficiency is a virtue for its own sake whether it turns out you need speed or capacity or merely to introduce as small a load on the systems as is reasonable.
On the subject of other projects having something to offer, we watch them all and think long and hard about what they tell the world. This is a small community and we should all respect the contributions of the others.
—Marty
@Marc Boorshtein:
Marc, very excellent points. The one case where I know performance is of the utmost concern, is if you are using the directory for email delivery, as is done @ Stanford. We deal with millions of emails every day, and if our servers couldn’t hold up to that load, we’d be in major trouble. Back when we were using Netscape DS, we had to have 6 servers out of our 9 servers dedicated to mail delivery, and that was four years ago, where we had only a fraction of the mail volume that we do today. Quite frankly, I’ve not seen another directory server that could handle our mail delivery needs, and that’s just one portion of what Stanford’s directory servers do.
—Quanah
@Quanah Gibson-Mount: Which brings up another point – when most people see that their deployed applications can only run at X ops/second, they become convinced that it will only ever be good for that small capacity, and they just accept that as truth. The poor efficiency of the most heavily marketed directory products therefore inherently limits the scope of deployments; it inherently prevents LDAP from being usefully applied in all the places that it could (and should) be used. Despite all its problems, LDAP is still pretty cool technology and deserves to be in more places than the current crop of minds/imaginations have taken it. We’ve taken LDAP beyond those recognized/false limits, and we will continue to take it further.
@Marc Boorshtein:
Marc – first, just echoing the thanks for a thoughtful response.
re: performance, and application limits – OK, that’s true for one application. It’s a pretty poor use of directories if it is only used by a single application. The point of providing distributed access to centralized information is to allow it to be shared by disparate applications.
re: a few more milliseconds won’t matter – and so you descend the slippery slope. A few more milliseconds in my .Net widget won’t matter. A few more milliseconds in my input-form validator won’t matter. On and on it goes. It all adds up. Every millisecond does matter. If it costs an engineer 100 hours to optimize away a 1 second delay in an application that is used by 1 million people, then that 100 hours is worth it. The time spent is nothing compared to the time saved, and the savings keeps paying back over the life of the app. When you genuinely care about your users, this is the decision you make. In an open source project, with no shortsighted shareholders calling the shots, there is no justification to choose anything else.
re: fewer C/C++ programmers – this may be true, but that doesn’t mean the solution is to hire more Java programmers. There are fewer computer science and engineering graduates coming out of US universities, but that doesn’t mean the solution is to hire more overseas engineers. When you identify a problem, fix the actual problem; “workarounds” will only work for so long.
re: competition – in reality, external competition is one of the most wasteful possible ways of developing a solution. Most people already seem to understand the undesirability of forking an existing project, but for some reason they fail to follow that line of thought to its logical conclusion. In software, just like in life, the only competition that matters is internal – self-improvement. OpenLDAP 2.1 was 200 times faster than OpenLDAP 2.0, not because we were aiming at some external performance target. It got there simply because we took the time to analyze it in great detail and question every design decision. When you engage in a process like that, cooperation is the most efficient way forward, because cooperation allows you to bring many different peoples’ experience to bear on answering those design questions. Yes, of course the members of the various projects have things to contribute. But working in separate projects slows the exchange of information, so it heavily dilutes those benefits. And as much as we may acknowledge that “one size doesn’t fit all,” OpenLDAP has proven itself to scale from tiny embedded systems, cellphones, whatever, up to mainframes and supercomputers. It’s the closest thing to an ideal platform out there, and it keeps getting better. So aside from the waste inherent in external competition, and the waste in impeding the exchange of ideas in relatively incompatible projects, there’s also the waste of effort invested in inferior platforms to bring them up to par. Life is short, too short to be spent like this.
Well, I think you missed the point of my argument. I wasn’t saying that its OK to write sloppy code for the sake of getting something done. What I’m saying is that perhaps another directory server has a feature that is better suited to the customer needs. Maybe you need centralized management, maybe an application you are deploying is only certified on a specific platform. Maybe the cost of integration at top performance is higher then the cost of integration at good enough performance. So I would agree that we should always strive to write the best code we can, but just because a product is slower doesn’t mean it’s a poor product.
As for for Java vs C++ my point was why many (such as the ApacheDS team) argue Java based infrastructure is better then an infrastructure written in C/C++. I don’t think it’s a matter of education or anything else. Its more expensive to write something in C/C++ then it is to write it in Java. The same argument can be made as to why it’s better to code in C/C++ then in assembly.
Finally, I wasn’t saying that OpenLDAP doesn’t scale. I’ll assume it does based on the testimonials I’ve read. I was making a more general statement.
(oop, I think I hit the wrong key…)
.. except if it transform the code to a unmaintanable peice of garbage)
Last, I will add that I totally desagree wit the statement ‘external competition is one of the most wasteful possible ways of developing a solution’. Microsoft would have landed such a sentence everybody would have jumped crazy in all direction. But I understand what you mean. In fact, when you start another project, it’s not only because you want or need to compete, but also because you have a true believe that your solution can bring something better, an advantage for users. I personaly find it pretty exciting to know that other are trying to improve their products, because it forces you to stay focused. But cooperation is good. Anyway, we don’t have to agree on this personnal opinion, this is not really important. What is important is the project quality, and the effort to improve them.
(Note : this post is the beginning of my previous post. I hit the wrong key …)
Lot of posts those last days, and really interesting ones !
Marc post was really a good one. I agree with most of it. I must say that all the other posts have valid points too. The C(++)/Java comparison is quite a complicated and balanced one. I agree with Marty that using C(++) is really an advantage for very loaded servers.
Quanah mentionned the millions of mails received every day at Standofrd University. I don’t know if the load is equaly spreaded on the 24 hours (I doubt), but even with 10 M search a day is just around 100 request per second, which is not a big number (even for ADS ;) but I’m pretty sure that you have bursts which may need to deal with thousands of requests per second. So, yes, speed is important.
I’m not any more thinking that there is a barier or at least a clear frontier between utility layers and enterprise applications. So far, some of the major players are using Java for critical systems (I won’t give any name of companies who let you bid for some goodies on the net…). I also worked for huge telco company using only Java, even for very loaded applications. But on the opposite side, I must admit that there is no RDBMS Java based which can compete with C written RDBMS. This is just a fact, as of 2007. I would say it will take some time for ADS or OpenDS to reach OpenLdap level of performance, if only it’s possible. Anyway, trying to do so is quite challenging, an can only drive those products to be better.
Howard mentioned that low performance is slowing down LDAP adoption. I don’t think this is the primary reason. Ldap concepts are pretty difficult to grasp, and some libraries are encouraging misconceptions about very basic operations like Bind just mixing its semantic with other operation (I was specifically thinking about JNDI). And people have been conditionned to “think” that all data should be stored in RDBMS… Not easy to change this state of mind ! (btw, yes every ms is important. When you see a way to make your code faster, then you should fix the code, except if it transform the code to …
@elecharny:
re: Microsoft as a counterexample for competition – my point about cooperation obviously only applies in an open source environment. Broad-scale cooperation is only feasible when there is total visibility into a technology, and all of my points are based on open source as a given.
With closed source and balkanized OS projects you invariably run into “Not Invented Here” syndrome, and then a lot of wheel-reinvention. But in open source “invented here” vs “invented there” is really meaningless. When everyone is cooperating on solving the same problem, everywhere is “here.”
Competition is only a necessary framework when sharing isn’t the norm. Because Microsoft doesn’t share openly, if they have a product that does 99% of what you wanted but you want to add one or two more features, you’re forced to recreate the entire product yourself and then finally add the features you wanted. But in open source, all you need to do is contribute the features you wanted, then go on your merry way. No wasted duplication of effort.
As for Java making coding easier or cheaper than C, and C vs assembler – perhaps. The old joke was that C is the user-friendly frontend to the PDP11 assembler. So C is hard – so what? Nothing worthwhile in life is ever easy. It takes discipline to write good code, no matter what language you write in. A tool that makes it easier for one to write 10x more mediocre code in a given amount of time really isn’t doing anyone any favors. A tool like Java that actively prevents good programmers from writing great code is clearly a burden, not a boon. E.g., the caching mechanisms in ApacheDS and OpenDS – Java’s garbage collection inherently prevents you from having the necessary control of your cache memory. Sure, basic memory allocation in C is tedious and maybe it’s better not to force the programmer to track every little detail. But there are other solutions to that problem (e.g. pool-based allocators in Apache and Samba) that don’t strangle you with even worse problems.
Ultimately, tools should only assist you in doing what you intended, they should not dictate to you how things must be done. Until we get to ubiquitous AIs that can integrate vastly more information than human minds can process, good programmers will always make better decisions than embedded algorithms. (And if we ever get there, we will probably have made ourselves extinct.)
@elecharny:
Quite right, the load is not evenly distributed. Most days, it only goes upwards towards 200 searches/second. However, we do get periodic spikes:
shows we’ve had a spike at least once in the last year hitting around 3500 searches/second.
—Quanah
@Quanah Gibson-Mount: Damn thing ate my URL. I’ve added it above. :P
I think LDAP will become obsolete. At its heart LDAP is just an underpowered way to maintain and provide data that could easily be stored in a database without a special LDAP protocol or the associated archaic technology to go along with it. That said- good job everyone on your projects.
No trackbacks: