Could someone with experiences in deploying FDS/RHDS (or even before that) shed some light on your largest deployment of directory? For example: - total #users - average # of concurrent users (at the same time) - total #objects in the system - hardware specs - how many servers - network topology - biggest problem encountered - ... I''m just trying to get a feel about the hardware requirements. Numbers from the Sun Directory is ok too. If you don''t mind sharing that. thanks a lot. csp
--- Chen Shaopeng wrote:> Could someone with experiences in deploying FDS/RHDS > (or even before > that) shed some light on your largest deployment of > directory? > > For example: > > - total #users > - average # of concurrent users (at the same time) > - total #objects in the system > - hardware specs > - how many servers > - network topology > - biggest problem encountered > - ... > > I''m just trying to get a feel about the hardware > requirements. > Numbers from the Sun Directory is ok too. > > If you don''t mind sharing that. > > thanks a lot.Heh, would be a great way for us, newbies, to learn about the specific requirements of FDS too. That could serve as guideline for us. Other aspects can be learned by hacking the code, studying the protocols, etc. But this only can be learned through experience, the hard way by screwing up yourself, or by learning from other people''s experience (which I hope to learn more from this list). This is what I found most lacking. Everyone seems to have to spend a lot of time, repeating the learning process the hard way, because there is lack of sharing of case studies and past experiences. Two of my high school classmates are studying architecture and civil engineering. They have all kinds of case studies, experiences, past failures and successes. And very detailed besides that. You can easily use them as guideline for new designs. Some are no-no, some are best practices, etc. They were laughing at what we call "software engineering", because they can easily prove at what load their bridge will crash, but I have no way to prove at what load my server will crash. Sure, it is easy to say that computer and software evolve much faster, but still, this domain seems to be characterized by the lack of rigorous and scientific measurement. No, I''m talking about the O() thing, that''s nothing compared to other engineering fields. I study the linux kernel too, and there''s also no way to prove the reliability of the system. Sorry that this has nothing to do with FDS, and sounds like a rant :) I love my field of study, but that does not seem to stand up to scientific review. Oh great, I just flamed two groups of people in one shot :) Ah, should go to sleep now, maybe tomorrow will be better. sz __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
speedy zinc wrote:> They were laughing at what we call "software > engineering", > because they can easily prove at what load their > bridge > will crash, but I have no way to prove at what load my > server will crash.No, they can not easily prove what the straw that will break the camel''s back is. They can only prove mathematical cases which would never happen in real life. For example, they might say that if you put a 500,000kg weight which occupies one square meter on the center of this bridge, then it will certainly break. They have no way of knowing how many cars/trucks the bridge can really hold before it breaks, because the cars will be spread at different distances, will weigh differently, travelling at different speeds, etc. They do not conduct those type of bridge system performance tests in real life to see where the bridge really breaks, because they don''t really want to break a bridge to find out (too costly, plus it would kill people and destroy a lot of cars). Therefore, we live with conservative capacity statements (estimates) from bridge engineers, which are derived from abstract mathematical cases and/or computer simulations. Computers have many variables which can be tuned for different purposes, so the absolute performance is difficult to abstractly state. I suggest you take some time to study system performance testing. Another thing worth understanding is the difference between software engineering and system engineering. Finally, I can''t give you details about my deployments because it would reveal sales related numbers of the system which I work with - something which I am not allowed to reveal because of business reasons. -- mike
--- Mike Jackson wrote:> Computers have many variables which can be tuned for > different purposes, > so the absolute performance is difficult to > abstractly state. >And that''s what I referred to: a systematic way. And I''d like to learn the best practice in a systematic way. At least in other field, there are certain ways (no matter how abstract that is) to evaluate certain things, and it is a recognized way besides that. But there is not much comparable thing in computer science. I have one year to go before graduating, and I think I''ve done quite a bit of programming practice during these school years. Currently, my graduation project is settled on (for now) modelling server behavior under heavy load, especially how to make the OS behave "consistently" regardless of the app that is taking heavy load. And I''d like to work out a model that is consistent all the time (or least, over 98% of the time). Maybe my technique is not right, but I find it quite hard to experiment, and especially hard to simulate heavy load and get an objective result, when I have only a one-machine setup which has to act as a server as well as 2000 clients or something. That''s when I think it would be great if people can publish some data that we can use as a base to study. What I found amazing is that there''s not much analysis data on previous project that students like me can study. And we have all heard about those multi-million and multi-billion dollars IT projects all the time. I think it is pretty safe to publish some analysis data in a huge projects like those, without revealing any industrial secrets or compromsing any privacy. My friend in civial engineering, when he submit a project on a small tiny bridge, he has to provide a lot of simulation and analysis data to show that the bridge would stand up. He can tweak the parameters, that''s fine, but that''s based on recognized frameworks. When we submit our project, in CS, the teacher will feed in pre-calculated input data, and look at the output. If the output matches, you pass. Most people think that''s fine, as long as they get the grade. What''s scary is that we work on a hard-core real-time OS kernel, which the professor insists on that''s the kind of OS that could be used to control a nuclear power center, and we used that same lousy method to evaluate student''s work. But that''s hardly scientific, isn''t it? Yeah, I know, I''ve learned the real-time kernel model, it''s different, and there are quite a bit of literature, and there''s even mathematical model, etc, but I don''t see much of a framework. Ah, all these ranting which has nothing to do with FDS... sorry :)> I suggest you take some time to study system > performance testing. > Another thing worth understanding is the difference > between software > engineering and system engineering. > > Finally, I can''t give you details about my > deployments because it would > reveal sales related numbers of the system which I > work with - something > which I am not allowed to reveal because of business > reasons. >Yeah, I know, but it could be anonymized, no? :) I promise I won''t beat on this thread again. Chen''s fault, I was doing some modelling work, and he threw in this question, can''t help it :) regards sz __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
> Finally, I can''t give you details about my deployments because it > would reveal sales related numbers of the system which I work with - > something which I am not allowed to reveal because of business reasons.Mike''s hit the nail on the head as regards why you''re not hearing answers here. I know about all kinds of huge deployments, but I''m not sure if that information is secret so I have to assume that it is. Because FDS and RHDS are quite new I doubt you will find many very large production deployments _yet_. There are certainly deployments on NSDS and SunDS that have millions of entries and 10''s of servers. You can do your own performance evaluation relatively easily to determine scaling for your application. The LDAP performance tools originally written for the Netscape ''Directory Server Resource Kit'' are handy for this. The best versions of these right now are in the Sun DS Resource Kit which you can download for free from their web site.