Good questions Eric,  there will be five DC's in this site that will be
doing authentication.  Exchange server and DC's that are dedicated to
exchange are in another site.  The main type of authentication will be two
types, regular logins via a logon on a client, others will be LDAP enabled
web/client applications making a connection checking credentials(mostly
web-based).   In our test environment we have the domain controllers already
behind a hardware load-balancer doing this and app's calling a VIP.
Applications and clients haven't seen any difference nor has this affected
the directory.  My background is from the web world of ASP.NET/ ASP.
Things like scalability, well designed applications is something I can
influence to insure the directory.  I suppose I could write my own stress
tools but would rather use a proven tool.

0) Will the entire DIT on this DC be cached in memory - how much physical
memory do we have? If dit<=2gb and ram>2gb, probably yes; if dit<=2.6gb and
ram>3gb, are we using /3gb?; if 64bit, how much physical memory do we have
(as that is the only limit really)?
Servers each have 2.5 gig of ram, some are DL380's g2/g3 models running 5
drives (OS/Logs on one mirrored set, database on another RAID 5 set of
disks) There are a couple of 4 proc ML570's, 2.5 gig ram 7 HD set (mirror
OS, mirror - Logs, RAID 5 - database)

1) What is functionality level of this domain (2k mixed or 2k native or 2k03
functional) and is the DC also a GC?
2003 functionality

2) How many other domains in forest?
This only has two domains in production Forest, one root domain, one child
domain.

3) How many trusts to domains in other forests and downlevel domains?
Three one way trusts to lab domains, the lab domains trust the production
domain but production doesn't trust the lab.

4) What does the disk subsystem look like on this box?  Where are dit and
logs stored?
Most DC's have a 5 drive set.  Mirrored OS, Logs together and one drive set
RAID 5 that holds the database, as I stated we have a couple DC's that have
a 7 drive set, Mirrored OS, Mirrored Logs, RAID 5 Set for database.  Note:
these servers that have the 7 drive setup hold the FSMO roles (RID, PDC
emulator)

Now you indicated ldap calls specifically...within ldap calls we typically
think of a few common things:
0)       can the query be satisfied from info already in cache
Not sure how to answer, I'm going to have to research how to utilize the
cache in AD.  Is this similiar to using the TEMPDB in SQL to store stuff in
memory?

1)       is the query hitting solid indexes
Not sure, but I'm already doing research to determine the high-volume LDAP
enabled applications, verifying the design to insure they aren't making
un-necessary calls to the directory.  We've already determined one
application by making one small change will save about 75% of the LDAP calls
(this is 1000's a day).   I'm fairly new to AD optomization using indexes,
etc.  We aren't fully rolled out into production yet so I have some time to
do more research and testing.   Any tips/tricks to doing AD and index
whitepapers would be apprecaited.

2)       within a "slow" query, there are fundamentally two reasons a query
can be slow:
a.       cpu-bound (such as a large index intersection)
b.       i/o-bound (badly-designed search filter that need walk a lot of
objects as it isn't hitting good indexes)

Good questions,

Steve Schofield
[EMAIL PROTECTED]

Microsoft MVP - ASP.NET
http://www.deviq.com

----- Original Message ----- 
From: Eric Fleischman
To: [EMAIL PROTECTED]
Sent: Sunday, May 09, 2004 5:22 PM
Subject: RE: [ActiveDir] LDAP stress tool for AD 2003


I'll weigh in here a bit...

I would argue there are lots of types of "stress" one can put on a DC and no
single metric measures everything. In my brain, I typically first go through
the following checklist of sorts to figure out what I'm looking at when
testing a given DC:
0) Will the entire DIT on this DC be cached in memory - how much physical
memory do we have? If dit<=2gb and ram>2gb, probably yes; if dit<=2.6gb and
ram>3gb, are we using /3gb?; if 64bit, how much physical memory do we have
(as that is the only limit really)?
1) What is functionality level of this domain (2k mixed or 2k native or 2k03
functional) and is the DC also a GC?
2) How many other domains in forest?
3) How many trusts to domains in other forests and downlevel domains?
4) What does the disk subsystem look like on this box? Where are dit and
logs stored?

After that is in mind, I ask myself this question: what is the most
important thing this DC will be doing that need be finished quickly? For
many DCs, the answer "authentication" probably comes to mind. For some
others (say GCs servicing Exchange) queries (such as ANR) may be your
answer. Still others might be some other application which it need satisfy.
It just depends upon the box.

Then, I look at the box and say logically "is this thing optimized for this
scenario". That's hard for me to quantify really. ;)

Now you indicated ldap calls specifically...within ldap calls we typically
think of a few common things:
0)       can the query be satisfied from info already in cache
1)       is the query hitting solid indexes
2)       within a "slow" query, there are fundamentally two reasons a query
can be slow:
a.       cpu-bound (such as a large index intersection)
b.       i/o-bound (badly-designed search filter that need walk a lot of
objects as it isn't hitting good indexes)

With the info in those three items, there should be something painstakingly
obvious to you: no single test can adequately measure each of these items.
Further, any item from that list or my earlier list of "general things this
DC does" can bog down the DC. We have some thresholds in place with default
values that are typically good (for example, only 4 LDAP op's processed per
physical CPU at a time by default, or perhaps for you MaxConcurrentAPI will
be your bottleneck..I have no idea) to prevent swamping other subsystems,
like I/O or secure channel. These things can be tweaked, but it's hard to
give huge advice that is general enough to be of any use..that's what the
defaults try to do. ;)

I have seen boxes tuned to ANR before that got abused by a bad
authentication setup and consequently, despite the amazing disk i/o
subsystem and other things done, came to its knees due to some bad client
requests and bad authentication configuration server-side. It's worth
watching everything the box does. ADPerf is a great tool for this.

If you give us some further insight in to the types of queries this box will
be servicing we might be of more help. At least I think I might be. ;)

~Eric





From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia
Sent: Sunday, May 09, 2004 10:59 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] LDAP stress tool for AD 2003

There is a load test tool for AD, called ADTest. Check it out at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=4814fe3f-92ce-4871-b8a4-99f98b3f4338&DisplayLang=en
-----Original Message----- 
From: [EMAIL PROTECTED] on behalf of Tony Murray
Sent: Sun 5/9/2004 8:40 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [ActiveDir] LDAP stress tool for AD 2003
Hi Steve

I'm not aware of anything specific.  The ldclt tool (comes with iPlanet)
might also work for AD, but I haven't tried it.

Being an ASP.NET guru you should be able to script something quite easily
:-)   You can track expensive and inefficient queries (good for a stress
test) by using the method described in the link below.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnactdir/html/efficientadapps.asp

Also be aware that the LDAP policies in place on the DCs will protect the DC
to a certain extent.  For example, the maximum number of records returned
for a single query is 1000, although you can change these by modifying the
MaxPageSize policy or by paging the results using the pagedResultsControl
LDAP control.

Tony




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield
Sent: Sonntag, 9. Mai 2004 16:07
To: [EMAIL PROTECTED]
Subject: [ActiveDir] LDAP stress tool for AD 2003
i have a need to find a tool that will help stress test LDAP calls to AD.
Anyone aware of a tool such as this?  I know in the web world MS has WAST
(web app stress tool), exchange has JETSTRESS, LOADSIM.

Steve Schofield
[EMAIL PROTECTED]

Microsoft MVP - ASP.NET
http://www.deviq.com


List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to