|
This is pretty nebulous.
You can look at perf counters to see some info that applies
to the overall DC.
If you want to see specifically how long a certain query
takes adfind with -elapsed or -selapsed is pretty useful (note that adfind does
a quick schema check too so if you want just the query you specified run use the
-dloid option though this will impact the ability to decode some binary
attributes). I have used that several times to find DCs that weren't responding
in a very performant way.
It reall depends on what you are looking for. A generic "it
takes 10 seconds to complete a query" doesn't help you much... What if
there were hundreds of small queries that took .05 second and a couple of
big ones that took hundreds of seconds. 10 seconds tells you nothing. You need
to know the specifics of the query and what you expect out of it. This
means baseline and then watch against that baseline. A query for
objectclass=user while generally inefficient would have different response times
for every domain depending on the indexing of objectclass and number of objects,
etc. I have seen several domains where objectclass=user is just fine and the
folks think it is the perfect query. Usually these are in the test labs of
developers with incomplete data sets and these queries are then assumed to
be good for any enterprise...
joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Centenni, Jason Sent: Tuesday, December 07, 2004 9:14 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] LDAP Capacity Planning On the same topic.
Anyone know of a “free” LDAP response time tool? Anyone know if MOM does this?
Jason From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Mulnick,
Al Can you give some more
information about what those limits were and how they "worked" around
them? I'm interested in context because there are a lot of variables
here. I've typically seen a
lot of folks that just write poor apps and trip the thresholds of AD that are
there to protect the DC/GC's. Those thresholds are typically set by engineers
meaning that the conversation often goes something like, "Q:Where should we set
the limits to protect as many people as possible? A:50 Real Answer: 75, but if
we let them get that close, they'll likely go over, so let's set it to 50 and
they'll never break that threshold" The apps that are well
written can often deal with this without issue, but it would help to know the
app, how they ran into a problem and what you did to get them around
it. Al From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Rachui,
Scott I have an interesting question
that's come up recently... I have some customers who have
recently seen some issues with their application and the default LDAP Query
Policy limits. We've worked through that issue, but the customer is now
wanting us to explain to them how we're going to monitor LDAP performance and
capacity so that we see problems in the future before the customer encounters
them. At the same time, the customer is asking us to give them the
theoretical limits that we can set our LDAP Query Policies to without harming
our Active Directory infrastructure. This will theoretically give them
some sense of their boundaries (if they want to extend their application, and
they know that there is a theoretical limit to the Query Policy, then they know
that's as far as they can go without overloading
AD). At this point, I am not finding
much data on how I would go about this, so I thought I'd throw the question open
and see if any of you have had this experience in the past. Any ideas on
where I can go for tools or solutions, or even ideas of things that I need to be
monitoring that will give me this sort of data, will be much
appreciated. Thanks, Scott
Rachui |
Title: [ActiveDir] Black Login Screen
