Que tal
Measure-Command {get-aduser -filter * -properties *|select $_.givenname,$_.sn,$_.mail, $_.mailnickname}
ou algo similar (dependendo de quais atributos etc suas consultas do aplicativo)?
Windows Server 2008 / Active Directory
Existe uma maneira de medir o tempo de resposta para consultas no AD? Eu tenho um aplicativo que verifica se um usuário existe no AD e, ultimamente, isso parece estar demorando um pouco (30-40 segundos). Gostaria de saber se o atraso está no lado do servidor do AD ou com o próprio aplicativo.
A csvde seria a melhor maneira de fazer isso? Ou existe uma ferramenta especial disponível para medir o desempenho das consultas do AD? Estou aberto a usar utilitários de terceiros, se isso fornecer uma visão mais completa do que está acontecendo.
Que tal
Measure-Command {get-aduser -filter * -properties *|select $_.givenname,$_.sn,$_.mail, $_.mailnickname}
ou algo similar (dependendo de quais atributos etc suas consultas do aplicativo)?
Se você suspeitar de algo no lado do AD, há uma nova funcionalidade que fornece um desempenho detalhado nos logs de eventos:
O hotfix adiciona dados de desempenho ao log de eventos do Active Directory no Windows Server 2012/2008 R2 SP1
link
Este artigo apresenta um hotfix que adiciona dados de desempenho ao log de eventos do Active Directory em um controlador de domínio baseado no Windows Server 2012 ou no Windows Server 2008 R2 Service Pack 1 (SP1). Depois de instalar esse hotfix, o controlador de domínio ativa filtros adicionais para registrar os seguintes dados de desempenho:
Field Description
callTime
Call time (in milliseconds)
entriesReturned
Entries returned
entriesVisited
Entries visited
filter
Used filter
index
Used indexes
pagesReferenced
Pages referenced
pagesRead
Pages read from disk
pagesPreread
Pages pre-read from disk
pagesDirtied
Clean pages modified
pagesRedirtied
Dirty pages modified
Observação: você pode coletar os dados de desempenho no log de eventos do Active Directory para analisar a causa de uma falha.
Depois de instalar esse hotfix, o trabalho necessário para solucionar problemas que envolvem uso inesperadamente alto da CPU no processo Lsass.exe e tempos longos de logon é reduzido. Mais especificamente, os filtros adicionais que são descritos na seção "Sintomas" são adicionados ao evento ID 1644. Quando o nível de log de engenharia de campo é definido, identificação de evento 1644 também pode ser registrada quando uma consulta LDAP excede uma limite de tempo. O limite de tempo é configurado em um valor DWORD chamado Search Time Threshold (milissegundos) localizado na seguinte subchave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Quando o nível de criação de log de engenharia de campo está habilitado e a entrada de registro Limite de tempo de pesquisa (milissegundos) não é usada ou definida como 0, o valor padrão do limite de tempo é 300.000 milissegundos.
Para obter mais informações sobre como usar o evento 1644 para solucionar problemas de desempenho de consulta LDAP, visite o seguinte site da Microsoft:
Criando aplicativos habilitados para Microsoft Active Directory mais eficientes
link
O que é engraçado é que costumava haver (talvez ainda haja uma rápida pesquisa no Google) uma ferramenta na Novell chamada "Elapsed Time" que fazia algo muito semelhante a isso.
Parece que o ADFind do JoeWare pode lhe dar tempo decorrido, embora isso possa ajudar.
Parece que esses dois switches farão o seguinte:
-elapsed Display elapsed time in seconds that the search occupied.
-selapsed Display elapsed time in seconds for various points of execution.