I've dissected a bit and put some info inline. I'm a bit tired so sorry if it is a bit incoherent. ;)
Eric (would have been ~Eric but Joe's been making fun of that as of late ;)) Eric Fleischman Escalation Engineer Platforms Critical Problem Resolution (CPR) - Directory Services -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Sunday, May 09, 2004 6:33 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] LDAP stress tool for AD 2003 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) [EFLEIS] - Getting the DIT and logs on different physical gives you an umph in perf, I'd go down that road if it is an option. How big is the DIT? 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 [EFLEIS] - Reason I asked: users in a domain which is 2k native or greater needs to talk to a GC during auth. Therefore, you want GCs to be plentiful. I really like making all of my DCs in to GCs in high-load sites. 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? [EFLEIS] - We do it for you, it's not something you utilize per se. We cache stuff for you and have algorithms to decide what to cache. In 2k03, we'll cache up to 2gb of stuff (or less if there is memory pressure of course....we back off if we see memory being used heavily) without /3gb, up to about 2.6gb if you have /3gb enabled. Oh, that's on 32bit. On 64bit the sky's the limit. If your dit is >2gb (2.6 if you have more physical ram and /3gb) you'll want to think a bit about this and what sorts of inefficient searches you have. If the whole thing fits in cache, sure we want efficient searches, but it isn't nearly as bad as we don't take a huge i/o hit typically. 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. [EFLEIS] - Ah! Yes, there are two ways I'd suggest tackling this: a) Enable inefficient and expensive search logging. Let the box sit for day, then look at the logs and pick out the expensive ones. Of course investigate the most expensive ones first (maybe the ones that appear most) then work your way down the list as appropriate. That is documented here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnactdi r/html/efficientadapps.asp Note the info on the STATS control....if you have a slow query, run the query in LDP or some other such searching tool and enable the STATS spew, show me the output and I can show you a way to make it faster as well as explain why it is slow. b) adperf is a solid tool for understanding what AD is chewing on. ADPerf is not for the faint of heart though....personally I usually use adperf to understand then I debug lsass to understand in depth if I want to understand something in more depth. But adperf tells you where your traffic is on a box if you are starting cold. It's a solid tool, but an investment of time. 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-4 871-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/dnactdi r/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/ 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/
