Condividi tramite

Come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NTLM usando l'impostazione MaxConcurrentApi

  • Articolo

Questo articolo descrive come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NTLM usando l'impostazione MaxConcurrentApi.

Numero KB originale: 2688798

Introduzione

Un aumento della consumerizzazione della tecnologia dell'informazione aziendale (aumento dei dispositivi orientati ai consumatori, ad esempio smartphone e tablet usati nell'azienda) ha portato ad aumentare il numero di scenari in cui le aziende possono riscontrare un notevole aumento dell'autenticazione legacy nei propri ambienti aziendali. Questo aumento dell'autenticazione legacy può causare problemi di prestazioni, ad esempio ritardi o timeout per i client.

Quando si rilevano timeout o ritardi di autenticazione (noti anche come colli di bottiglia MaxConcurrentApi) in un ambiente, il modo tipico per risolvere il problema consiste nell'aumentare il numero massimo consentito di thread di lavoro che esezionano tale autenticazione. A tale scopo, modificare il valore del Registro di sistema MaxConcurrentApi e quindi riavviare il servizio Accesso rete nei server.

Identificare quali server sono vittime del collo di bottiglia e quali server sono effettivamente la fonte dei ritardi del collo di bottiglia può essere difficile. Questo articolo descrive come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NT LAN Manager (NTLM) usando l'impostazione MaxConcurrentApi. Questo articolo contiene indicazioni per gli amministratori nell'identificazione dei server in cui generare il valore MaxConcurrentApi e l'importo a cui impostare tale valore.

Risoluzione

Importante

In questa sezione, nei passaggi del metodo o dell'attività viene illustrata la modalità di modifica del Registro di sistema. Se, tuttavia, si modifica il Registro di sistema in modo errato, possono verificarsi gravi problemi. Pertanto, assicurarsi di osservare attentamente la procedura seguente. Per una maggiore protezione, eseguire il backup del Registro di sistema prima di modificarlo. Successivamente, è possibile ripristinare il Registro di sistema se si verifica un problema. Per ulteriori informazioni su come eseguire il backup e il ripristino del registro, fare clic sul numero dell'articolo seguente per visualizzare l'articolo nella Microsoft Knowledge Base:
322756 Come eseguire il backup e il ripristino del registro in Windows

Per risolvere questo problema, è necessario esaminare i dati sulle prestazioni acquisiti da tutti i server coinvolti nello scenario. È quindi possibile provare ad aumentare l'impostazione MaxConcurrentApi in tali server che mostrano una perdita di prestazioni.

Sono Netlogon disponibili eventi che segnalano problemi di autenticazione NTLM, vedere:
2654097 Sono disponibili nuove voci del registro eventi che tengono traccia dei ritardi e degli errori di autenticazione NTLM in Windows Server 2008 R2

Gli eventi indicano l'attività per due contatori:

  • Eventi 5818/5819: sono presenti "Camerieri semafori", se gli eventi sono abilitati.
  • Eventi 5816/5817: sono presenti "Timeout semafori".

Per determinare il valore MaxConcurrentApi migliore per i server, è necessario riunire e calcolare diversi punti dati usando una formula. I dati da usare per stimare MaxConcurrentApi sono i seguenti:

  • Net Logon semaphore acquisisce
  • Timeout del semaforo di accesso net
  • Tempo medio di blocco del semaforo di accesso netto
  • Durata della registrazione delle prestazioni completata, misurata in secondi

Dopo aver ottenuto i dati, è possibile usare la formula seguente per stimare il valore MaxConcurrentApi corretto:(semaphore_acquires + semaphore_time outs) * average_semaphore_hold_time / time_collection_length = New_MaxConcurrentApi_setting <
Dopo aver raccolto i dati sulle prestazioni dell'accesso netto da quando il server era in fase di caricamento dell'autenticazione, è necessario determinare la durata del processo di raccolta dati esaminando l'ora iniziale e di fine della visualizzazione riga.

Nota

I segnaposto semaphore_acquires e semaphore_time-out rappresentano numeri cumulativi che indicano il numero di timeout che si sono verificati durante la durata di un canale di sicurezza. Di conseguenza, è probabile che i numeri non inizino a zero nei dati raccolti. Il numero iniziale deve essere sottratto dal numero finale quando si usa La visualizzazione riga nella Monitor prestazioni (Perfmon.msc). Usare quindi questo numero calcolato nella formula per la nuova impostazione MaxConcurrentApi. Per determinare il numero di timeout che si sono verificati durante la raccolta dei dati, utilizzare Visualizzazione riga in Perfmon.msc e posizionare il puntatore del mouse sulla riga per il contatore alla fine e all'inizio e quindi sottrarre il numero iniziale dal numero finale. Questo risultato è il numero da inserire nell'equazione.

Il tempo medio di attesa del semaforo può essere determinato modificando la visualizzazione predefinita da Visualizzazione riga a Visualizzazione report in Perfmon.msc. Ad esempio, si consideri il seguente scenario:

  • Il semaforo acquisisce il valore è 8.286.
  • Il valore di timeout del semaforo è 883.
  • Il tempo medio di attesa semaforo è .5 (ovvero, mezzo secondo).
  • La durata della creazione di report è di 90 secondi.

In questo scenario, la formula sarà la seguente:
(8.286 + 883) *.5 / 90 =< 51

Se il valore derivato dalla formula è 150 o superiore, è necessario aggiungere altri server per gestire il carico di autenticazione legacy.

Se il valore è minore di 150, è necessario modificare il valore del Registro di sistema MaxConcurrentApi in tale server sul valore suggerito dalla formula o su un valore maggiore.

Nota

Se si decide di aumentare il valore MaxConcurrentApi a un valore maggiore di 10, il carico e le prestazioni dell'impostazione desiderata devono essere testati in un ambiente non di produzione prima di implementare la modifica in un ambiente di produzione. È consigliabile assicurarsi che l'aumento di questo valore non causi altri colli di bottiglia della risorsa. Tenere inoltre presente che le condizioni di carico possono cambiare in base a ogni scenario e ambiente aziendale. Pertanto, il valore MaxConcurrentApi potrebbe avere un'impostazione diversa in un secondo momento se il carico del servizio cambia.

Per modificare l'impostazione MaxConcurrentApi, seguire questa procedura:

  1. Fare clic su Start, fare clic su Esegui, digitare regedite quindi fare clic su OK.

  2. Individuare e fare clic sulla sottochiave di registro seguente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. Scegliere Nuovo dal menu Modifica e quindi fare clic su Valore DWORD.

  4. Digitare MaxConcurrentApi e quindi premere INVIO.

  5. Scegliere Modifica dal menu Modifica.

  6. Digitare la nuova impostazione MaxConcurrentApi in decimale e quindi fare clic su OK.

  7. Al prompt dei comandi digitare il comando seguente e quindi premere INVIO:
    net stop netlogon

  8. Digitare il comando seguente e quindi premere INVIO:
    net start netlogon

Ulteriori informazioni

È possibile usare l'articolo della Knowledge Base seguente per identificare i sintomi lato client dei colli di bottiglia dell'autenticazione legacy in modo più dettagliato:
975363 Vengono richieste in modo intermittente le credenziali o i timeout dell'esperienza quando ci si connette a Servizi autenticati Il collo di bottiglia dell'autenticazione potrebbe trovarsi in più server nello scenario. Pertanto, è necessario assicurarsi che tutti i server in un determinato scenario abbiano i dati sulle prestazioni esaminati durante la manutenzione di carichi elevati.

I contatori per l'acquisizione del semaforo, per i timeout del semaforo e per il tempo medio di blocco semaforo devono essere esaminati in tutti i server applicazioni, i controller di dominio e i controller di dominio attendibili coinvolti nella manutenzione delle richieste client.

I dati sulle prestazioni devono essere rilevati mentre i server sono sottoposti a un carico elevato. Il carico elevato si verifica quando i server visualizzano la maggior parte delle richieste client. Ad esempio, in uno scenario del server di posta elettronica, il momento migliore per raccogliere i dati sulle prestazioni è quando gli utenti arrivano al lavoro e controllano i messaggi di posta elettronica.

Gli elementi aggiuntivi da considerare sono i seguenti:

  • Nessun valore significa che non è necessaria alcuna azione. I contatori Semaphore Holders e Semaphore Hold Time non mostreranno alcun valore a meno che non sia presente un carico prolungato in un server. Se non sono presenti valori, non è necessaria alcuna modifica nel valore MaxConcurrentApi.

  • Una dimensione non è adatta a tutti. Il valore MaxConcurrentApi può essere un valore diverso per ogni server. Questa situazione può essere causata da più server applicazioni che ottengono l'autenticazione da un singolo controller di dominio o da scenari simili in cui più server forniscono un volume di carico maggiore con cui il controller di dominio deve gestire.

  • Trust. Se gli utenti autenticati provengono da domini attendibili, può causare ritardi più lunghi, perché il controller di dominio locale deve attendere la risposta dal controller di dominio attendibile prima che il controller di dominio locale fornisca la risposta al server applicazioni.

  • Latenza di rete. La latenza di rete può anche svolgere un ruolo importante nel causare colli di bottiglia di MaxConcurrentApi. Questo problema può verificarsi quando il semaforo MaxConcurrentApi usa un contatore di timeout basato sul tempo in modo che i client non attendino un tempo illimitato per l'autenticazione legacy.

  • Collocazione. Se la latenza di rete esiste e causa ritardi e colli di bottiglia nel completamento dei thread MaxConcurrentApi, una soluzione comune consiste nell'inserire i server nella stessa posizione fisica in modo che la latenza di rete venga ridotta. In un modello di dominio in cui un dominio attendibile dispone di server CAS di Microsoft Exchange, ad esempio, e il dominio dell'utente si trova in un'altra area o in un sito di Active Directory, significa inserire i controller di dominio dell'utente nello stesso percorso fisico e nel sito di Active Directory dei server cas di Exchange e dei relativi controller di dominio.

  • Possibile ritardo downstream. Se il valore del contatore Semaphore Waiters è continuamente maggiore di 0 (zero) per qualsiasi momento e il valore Holders semaforo è minore dell'impostazione MaxConcurrentApi in tale server, il collo di bottiglia non si trova in tale server. In questo caso, cercare il controller di dominio citato nel nome del contatore elencato come nome di dominio completo del computer host. I dati sulle prestazioni dei semaphore del controller di dominio e dei titolari di semaforo devono essere esaminati.

  • Modifiche al carico o alla configurazione di rete. Le modifiche future del carico in corso di manutenzione o nelle configurazioni di rete possono produrre latenza di rete e potrebbero causare la necessità di valutare nuovamente l'impostazione MaxConcurrentApi corretta. Per gli ambienti in cui il volume di autenticazione legacy viene considerato nella misura in cui vengono esaminate le impostazioni MaxConcurrentApi, è consigliabile monitorare continuamente ed esaminare i contatori degli oggetti prestazioni Accesso rete. È possibile farlo usando gli agenti di raccolta dati perfmon.msc pianificati, usando Microsoft System Center Operations Manager o altri metodi.

  • Massimo Windows Server 2008. L'impostazione massima consentita per MaxConcurrentApi in Windows Server 2008 e nelle versioni successive di Windows è 150. Applicare l'hotfix descritto nell'articolo della Knowledge Base seguente per avere l'impostazione massima di 150 disponibile se il server in uso non esegue Windows Server 2008 R2:
    975363 Vengono richieste in modo intermittente le credenziali o i timeout dell'esperienza quando ci si connette a Servizi autenticati

  • Massimo Windows Server 2003. L'impostazione massima consentita per MaxConcurrentApi in Windows Server 2003 e nelle versioni precedenti è 10.

  • Impostazioni predefinite di Windows Server 2012 e versioni successive. Il valore predefinito per MaxConcurrentApi è stato modificato in Windows Server 2012. È 10 per i server membri e i controller di dominio. Rimane a 1 per workstation membro.

  • Contatori delle prestazioni e Windows Server 2003. La versione originale di Windows Server 2003 non contiene i contatori delle prestazioni net logon. È possibile applicare un hotfix per aggiungerlo.

L'identificazione di client o servizi non autorizzati o sconosciuti che eseguono l'autenticazione NTLM ripetuta e continua può essere utile quando si vuole ridurre il carico di autenticazione NTLM complessivo e quindi ridurre il numero di utilizzi del semaforo MaxConcurrentApi. L'autenticazione ripetuta in questo modo può essere identificata usando la registrazione di debug del servizio Accesso rete. Per altre informazioni su come usare il file Netlogon.log per eseguire il debug del servizio Accesso rete, fare clic sul numero di articolo seguente per visualizzare l'articolo della Microsoft Knowledge Base:
109626 Abilitazione della registrazione di debug per il servizio Accesso rete

Il contatore Perfmon.msc per le autenticazioni NTLM nell'oggetto Security System-Wide Statistics non riflette il numero di utilizzi del thread monitorato MaxConcurrentApi. Non esiste alcuna correlazione uno-a-uno tra l'utilizzo del semaforo MaxConcurrentApi visualizzato nel contatore delle prestazioni Accesso netto e gli incrementi del contatore di autenticazione NTLM. Il contatore di autenticazione NTLM non è utile per determinare il valore MaxConcurrentApi migliore.

Inoltre, è probabile che i timeout delle prestazioni di autenticazione legacy correlati a MaxConcurrentApi vengano visualizzati ma non riflesse in alcun contatore delle prestazioni diverso dal contatore net logon. Ciò significa che altre metriche delle prestazioni, ad esempio l'uso della CPU e del disco e della rete, possono non mostrare alcun carico anche se il carico MaxConcurrentApi è pesante e gli utenti riscontrano problemi.

È possibile eseguire una procedura aggiuntiva per ridurre al minimo i controller di dominio con voci nel log di debug del servizio Accesso rete che indicano che i client inviano <null>\username anziché domainname\username. Questa procedura è descritta nell'articolo seguente della Microsoft Knowledge Base:
923241 Il processo di Lsass.exe potrebbe smettere di rispondere se si dispone di molti trust esterni in un controller di dominio di Active Directory