Limiti software statici e configurabili per SharePoint Server 2016
**Si applica a:**Project Server 2016, SharePoint Server 2016
**Ultima modifica dell'argomento:**2018-01-08
Riepilogo: informazioni sui limiti di prestazioni e capacità testati di SharePoint Server 2016 e sulla correlazione tra limiti e prestazioni accettabili.
In questo articolo vengono illustrati i limiti software statici e configurabili di SharePoint Server 2016. Nello specifico si tratta di:
Limiti statici che non possono essere superati da progettazione.
Soglie, ovvero limiti configurabili che possono essere superati per soddisfare requisiti specifici.
Limiti supportati, ovvero limiti configurabili a cui è stato associato per impostazione predefinita un valore testato.
Nota
Le informazioni sulla pianificazione della capacità contenute in questo documento possono essere utilizzate come linee guida per la pianificazione. Si basano su test eseguiti presso Microsoft su proprietà attive. I risultati ottenuti tuttavia possono variare a seconda delle attrezzature utilizzate e delle caratteristiche e funzionalità implementate per i propri siti.
Contenuto dell'articolo:
Panoramica dei limiti statici e configurabili
Limiti statici, soglie e limiti supportati
Modalità di definizione dei limiti
Limiti statici e configurabili
Limiti in base alla gerarchia
Limiti relativi alle applicazioni Web
Limiti relativi a SharePoint Server
Limiti relativi ai database del contenuto
Limiti relativi alle raccolte siti
Limiti relativi agli elenchi e alle raccolte
Limiti relativi alle colonne
Limiti relativi alle pagine
Limiti in base alla funzionalità
Limiti relativi alla ricerca
Limiti relativi al servizio profili utente
Limiti relativi alla distribuzione del contenuto
Limiti relativi ai blog
Limiti relativi a Servizi di integrazione applicativa
Limiti relativi ai flussi di lavoro
Limiti relativi agli archivi termini (database) dei metadati gestiti
Limiti relativi a Visio Services
Limiti relativi a PerformancePoint Services
Limiti relativi a Word Automation Services
Limiti relativi al servizio di traduzione automatica
Limiti relativi al servizio Office Online
Limiti relativi a Project Server
Limiti relativi alle app di SharePoint
Limiti relativi al servizio cache distribuita
Limiti vari
Panoramica dei limiti statici e configurabili
In questo articolo vengono forniti dati utili per comprendere i limiti di capacità e di prestazioni testati di SharePoint Server 2016 e vengono indicate linee guida per ottenere prestazioni accettabili a fronte dei limiti previsti. Le informazioni contenute in questo articolo consentono di stabilire se il livello di prestazioni e i limiti di capacità della distribuzione pianificata sono accettabili e di configurare in modo appropriato limiti per l'ambiente in uso.
Le linee guida e i risultati dei test forniti in questo articolo si applicano a una singola farm di SharePoint Server 2016. L'aggiunta di server all'installazione aumenta la velocità effettiva di una server farm senza eventualmente influire sui limiti di capacità degli oggetti elencati nelle tabelle della sezione Limiti statici e configurabili più avanti in questo argomento. L'aumento della velocità effettiva potrebbe essere necessario per ottenere prestazioni accettabili per grandi quantità di oggetti. In alcuni casi, per soddisfare i requisiti di una soluzione che prevede un numero elevato di oggetti, potrebbe essere necessario utilizzare più server nella farm.
Esistono molti fattori che, in aree diverse, possono influire sulle prestazioni in un determinato ambiente. Alcuni dei consigli e dei risultati dei test forniti in questo articolo potrebbero essere correlati a funzionalità o operazioni degli utenti che non riguardano l'ambiente in uso e pertanto non si applicano alla soluzione specifica. Per ottenere dati precisi relativi all'ambiente in uso, è in ogni caso fondamentale effettuare test accurati.
Limiti statici, soglie e limiti supportati
In SharePoint Server 2016 sono previsti alcuni limiti che sono configurati da progettazione e che non possono essere superati e altri limiti impostati su valori predefiniti che possono essere modificati dall'amministratore della farm. Esistono inoltre limiti non rappresentati da un valore configurabile, come ad esempio il numero di raccolte siti per ogni applicazione Web.
I limiti statici sono limiti assoluti che non possono essere superati da progettazione. È importante conoscerli per evitare ipotesi errate durante la progettazione della farm.
Un esempio di limite statico è rappresentato dal limite di 10 GB per le dimensioni dei documenti, in virtù del quale non è possibile configurare SharePoint Server 2016 per l'archiviazione di documenti di dimensioni superiori ai 10 GB. Questo è un valore assoluto incorporato che non può essere superato da progettazione.
Le soglie sono limiti con un valore predefinito che non possono essere superati a meno che tale valore non venga modificato. Le soglie in alcune circostanze possono essere superate per adeguarsi a cambiamenti nel progetto della farm, ma è importante essere consapevoli che questo può avere ripercussioni sulle prestazioni della farm e sul valore valido per altri limiti.
Il valore predefinito di alcune soglie può essere superato fino a un valore massimo assoluto. Un buon esempio di tale situazione è rappresentato dal limite di dimensione dei documenti. Per impostazione predefinita, la soglia relativa alle dimensioni dei documenti è 250 MB, ma può essere modificata in modo da supportare il limite massimo di 10 GB.
I limiti supportati definiscono il valore testato per un determinato parametro. I valori predefiniti per tali limiti sono stati definiti mediante attività di testing e rappresentano le limitazioni note del prodotto. Il superamento dei limiti supportati può causare risultati imprevisti, un calo significativo delle prestazioni o altri effetti negativi.
Alcuni limiti supportati sono parametri configurabili per cui è specificato per impostazione predefinita il valore consigliato, mentre altri limiti supportati riguardano parametri non rappresentati da un valore configurabile.
Un esempio di limite supportato è il numero di raccolte siti per ogni farm. Tale limite supportato corrisponde al numero più alto di raccolte siti per applicazione Web che ha soddisfatto i benchmark relativi alle prestazioni durante il testing.
È importante tenere presente che molti dei valori limite riportati in questo documento rappresentano un punto di una curva indicante un carico crescente delle risorse e allo stesso tempo una riduzione delle prestazioni man mano che il valore aumenta. Il superamento di determinati limiti, come ad esempio il numero di raccolte siti per ogni applicazione Web, può pertanto dare luogo a un calo frazionario delle prestazioni della farm. Nella maggior parte dei casi l'utilizzo del sistema in prossimità o al valore limite stabilito non è comunque una procedura consigliata, dal momento che gli obiettivi di prestazioni e affidabilità accettabili vengono raggiunti in modo ottimale quando una farm viene progettata mantenendo una situazione di equilibro ragionevole relativamente ai valori dei limiti.
Le soglie e i limiti supportati sono determinati dalle prestazioni. In altri termini, è possibile superare i valori predefiniti dei limiti ma, con l'aumentare del valore limite, le prestazioni della farm e il valore valido per altri limiti possono risentirne. È possibile modificare diversi limiti previsti in SharePoint Server 2016, ma è fondamentale sapere in che modo la modifica di un determinato limite incide su altre parti della farm.
Modalità di definizione dei limiti
In SharePoint Server 2016 le soglie e i limiti supportati vengono stabiliti mediante l'esecuzione di test e l'osservazione del comportamento della farm, la quale viene sottoposta a carichi crescenti fino al raggiungimento dei limiti operativi effettivi da parte dei servizi e delle attività della farm. Alcuni servizi e componenti della farm possono gestire un carico superiore a quello di altri elementi, pertanto in alcuni casi è necessario assegnare un valore limite basato su una media di diversi fattori.
Le osservazioni relative al comportamento della farm sotto carico quando vengono aggiunte raccolte siti indicano ad esempio che alcune funzionalità presentano livelli di latenza eccessivamente elevati mentre altre funzionalità continuano a operare entro parametri accettabili. Il valore massimo assegnato al numero di raccolte siti non è pertanto assoluto, bensì calcolato in base a una serie prevista di caratteristiche di utilizzo in cui le prestazioni globali della farm saranno accettabili al limite dato nella maggior parte delle situazioni.
Ovviamente, se alcuni servizi vengono eseguiti con parametri superiori a quelli utilizzati per il testing dei limiti, si ridurranno i limiti massimi validi per gli altri servizi. È perciò importante eseguire rigorosi esercizi di gestione della capacità e testing della scalabilità per distribuzioni specifiche per definire i limiti validi per l'ambiente in questione.
Nota: non viene fornita una descrizione dell'hardware utilizzato per convalidare i limiti riportati in questo documento perché tali limiti derivano da dati raccolti da farm e ambienti diversi.
Metafora della torta
Per comprendere la relazione tra le risorse hardware, carico e prestazioni, è importante visualizzare i fattori coinvolti e l'effetto reciproco.
Considerare la capacità di una farm come una torta, le cui dimensioni rappresentano l'aggregazione di fattori quali server, risorse hardware come CPU e RAM, capacità di archiviazione, operazioni di I/O al secondo su disco, larghezza di banda di rete e latenza. Le dimensioni della torta sono pertanto correlate alle risorse totali della farm. Aumentando le risorse, ad esempio i server della farm, si aumentano le dimensioni della torta.
La torta è suddivisa in sezioni che rappresentano il carico prodotto da diverse origini: richieste utente, query di ricerca, operazioni sulle funzionalità installate, processi timer e sovraccarico del sistema operativo. Ciascuna di queste sezioni deve condividere le risorse disponibili della farm. Se le dimensioni di una di tali sezioni aumentano, devono diminuire proporzionalmente le dimensioni delle altre sezioni. Poiché il carico di una farm non è statico, ad esempio le richieste utente potrebbero essere significative solo durante alcune ore del giorno, le dimensioni relative delle sezioni sono soggette a frequenti e continui mutamenti. Tuttavia ciascuna sezione deve mantenere una dimensione minima richiesta per funzionare normalmente e poiché le funzioni rappresentate da ogni sezione sono interdipendenti, aumentando le dimensioni di una sezione si possono sovraccaricare le altre sezioni riducendo al contempo le risorse disponibili per il relativo utilizzo.
Con questa metafora, l'obiettivo è progettare una farm creando una torta in grado di ospitare le dimensioni necessaire di ogni sezione in situazioni di carico di picco.
Considerare ora uno scenario in cui le richieste utente aumentano del 100% rispetto alle normali condizioni. Si supponga che quasi la metà delle richieste siano query di ricerca e che l'altra metà siano modifiche di documenti ed elenchi. Questo aumento del carico riduce le dimensioni delle altre sezioni della torta ma alcune funzionalità della farm devono compensare aumentando anche il carico di lavoro. Il servizio di ricerca deve elaborare più query, la maggior parte delle quali vengono gestite dalla cache, ma alcune query vengono passate ai server di database, aumentandone il carico di lavoro. Se il carico di lavoro dei server di database diventa troppo grande, aumenteranno le lunghezze della coda del disco, incrementando a sua volta la latenza di tutte le altre richieste.
Limiti statici e configurabili
In questa sezione sono riportati gli oggetti che possono fare parte di una soluzione e vengono fornite linee guida per prestazioni accettabili per ognuno di questi tipi di oggetto. Con la definizione "prestazioni accettabili" si intende che il sistema, così come è stato testato, è in grado di supportare quel determinato numero di oggetti, ma che tale numero non può essere superato senza un calo delle prestazioni o una riduzione del valore dei limiti correlati. Gli oggetti vengono elencati sia in base all'ambito che in base alla funzionalità. I dati relativi ai limiti vengono indicati con alcune note che descrivono le condizioni in cui viene ottenuto il limite in questione e collegamenti alle informazioni aggiuntive eventualmente disponibili.
Utilizzare le linee guida contenute in questo articolo per rivedere complessivamente i piani relativi alla soluzione. Se tali piani non sono conformi alle linee guida consigliate per uno o più oggetti, eseguire una o più delle operazioni seguenti:
Valutare la soluzione per accertarsi che vengano effettuate compensazioni in altre aree.
Contrassegnare tali aree per il testing e il monitoraggio mentre si prepara la distribuzione.
Riprogettare o partizionare la soluzione in modo da restare entro le linee guida relative alla capacità.
Limiti in base alla gerarchia
In questa sezione i limiti sono ordinati in base alla gerarchia logica di una farm di SharePoint Server 2016.
Limiti relativi alle applicazioni Web
Nella tabella seguente sono riportate le linee guida consigliate per le applicazioni Web.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Applicazione Web |
20 per farm |
Supportato |
È consigliabile limitare il più possibile il numero delle applicazioni Web. Dove possibile, creare ulteriori raccolte siti con nome basato sull'host invece di aggiungere applicazioni Web. |
Area |
5 per applicazione Web |
Statico |
Il numero di aree definite per una farm è specificato a livello di codice (hard-coded) come 5. Le aree sono Predefinita, Intranet, Extranet, Internet e Personalizzata. |
Percorso gestito per le raccolte siti con nome basato sull'host |
20 per farm |
Supportato |
I percorsi gestiti per le raccolte siti con nome basato sull'host si applicano a livello di farm. Ogni percorso gestito creato può essere applicato in qualsiasi applicazione Web. |
Percorso gestito per le raccolte siti basate sul percorso |
20 per applicazione Web |
Supportato |
I percorsi gestiti vengono memorizzati nella cache nel server Web e le risorse di CPU vengono utilizzate per elaborare le richieste in ingresso a fronte dell'elenco dei percorsi gestiti. I percorsi gestiti per le raccolte siti basate sul percorso si applicano a livello di applicazione Web. È possibile creare un set di percorsi gestiti diverso per ogni applicazione Web. Superando i 20 percorsi gestiti per applicazione Web, si aggiunge ulteriore carico al server Web per ogni richiesta. Se si prevede di superare i 20 percorsi gestiti in una determinata applicazione Web, è consigliabile testare se le prestazioni del sistema sono accettabili. |
Dimensioni della cache delle soluzioni |
300 MB per applicazione Web |
Soglia |
Il servizio InfoPath Forms si avvale della cache delle soluzioni per conservare in memoria le soluzioni e accelerarne il recupero. Se vengono superate le dimensioni della cache, le soluzioni verranno recuperate dal disco, con un conseguente rallentamento dei tempi di risposta. Per configurare le dimensioni della cache delle soluzioni, vedere Set-SPInfoPathFormsService. |
Limiti relativi a SharePoint Server
Nella tabella seguente sono riportate le linee guida consigliate per i server Web della farm.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Pool di applicazioni |
10 per server Web |
Soglia |
Il numero massimo è determinato dalle capacità dell'hardware. Questo limite dipende in grande misura dai fattori seguenti:
|
Limiti relativi ai database del contenuto
Nella tabella seguente sono riportate le linee guida consigliate per i database del contenuto.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Numero di database del contenuto |
500 per farm |
Supportato |
Il numero massimo di database del contenuto consentiti per ogni farm è 500. Con 500 database del contenuto per applicazione Web, non vi sono effetti sulle operazioni degli utenti finali, come ad esempio l'apertura del sito o delle raccolte siti. Per le operazioni amministrative, quale la creazione di una nuova raccolta siti, si riscontrerà invece un calo delle prestazioni. È consigliabile utilizzare PowerShell per gestire l'applicazione quando è presente un numero elevato di database del contenuto, in quanto in questi casi l'interfaccia di gestione può rallentarsi e gli spostamenti al suo interno possono essere più difficoltosi. Grazie a 200 GB per database del contenuto e a 500 database del contenuto per ogni farm, SharePoint Server 2016 supporta fino a 100 TB di dati per ogni farm. |
Dimensioni dei database del contenuto (scenari di utilizzo generali) |
200 GB per database del contenuto |
Supportato |
La dimensione predefinita corrisponde a 2047 MB, ma può essere aumentata fino a un massimo di 10 GB. È possibile che più raccolte siti condividano un database del contenuto singolo. Ogni raccolta siti deve essere completamente archiviata in un singolo database del contenuto. È consigliabile limitare le dimensioni dei database del contenuto a 200 GB, ad eccezione dei casi in cui si verificano le condizioni illustrate nelle righe seguenti di questa tabella. Se si utilizza Archiviazione BLOB remoti, il volume totale dello spazio di archiviazione BLOB remoti e dei metadati nel database del contenuto non deve superare il limite di 200 GB. |
Dimensioni dei database del contenuto (tutti gli scenari di utilizzo) |
4 TB per database del contenuto |
Supportato |
Sono supportati database del contenuto di dimensioni massime di 4 TB quando vengono soddisfatte le condizioni seguenti:
È consigliabile inoltre tenere conto dei fattori seguenti:
Importante Non si consiglia di utilizzare database del contenuto con dimensione superiore ai 4 TB, tranne che nei casi di archiviazione dei documenti (descritti nella successiva riga della tabella). Se in futuro è necessario aggiornare l'installazione di SharePoint Server 2016, aggiornare la raccolta di siti all'interno dei database del contenuto può rivelarsi complicato e richiedere tempo. |
Dimensioni dei database del contenuto (scenario di archiviazione dei documenti) |
Non è previsto un limite esplicito per i database del contenuto |
Supportato |
L'utilizzo di database del contenuto senza un limite di dimensioni esplicito in scenari di archiviazione dei documenti è supportato se vengono soddisfatti i requisiti seguenti:
|
Elementi di database del contenuto |
60 milioni di elementi, inclusi documenti ed elementi di elenco |
Supportato |
Il numero massimo di elementi per database del contenuto che è stato sottoposto a test in SharePoint Server 2016 è pari a 60 milioni di elementi, inclusi documenti ed elementi di elenco. Se si prevede di archiviare più di 60 milioni di elementi in SharePoint Server 2016, è necessario distribuire più database del contenuto. |
Raccolte siti per database del contenuto |
10.000 al massimo (2.500 raccolte siti non personali e 7.500 siti personali oppure soltanto 10.000 siti personali) |
Supportato |
È consigliabile limitare a 5.000 il numero delle raccolte siti in un database del contenuto. È tuttavia supportato fino a un massimo di 10.000 raccolte siti in uno stesso database. Si noti che, in un database del contenuto con un massimo di 10.000 raccolte siti in totale, non più di 2.500 possono essere raccolte siti non personali. È possibile supportare 10.00 raccolte siti personali se sono le uniche raccolte siti presenti nel database del contenuto. Questi limiti sono correlati alla velocità dell'aggiornamento. Più è elevato il numero delle raccolte siti in un database, più sarà lento l'aggiornamento sia del database che delle raccolte siti. Il limite relativo al numero di raccolte siti in un database è subordinato al limite relativo alle dimensioni di un database del contenuto con più di una raccolta siti. Man mano che aumenta il numero delle raccolte siti in un database, devono perciò diminuire le dimensioni medie delle raccolte siti in esso contenute. Superando il limite di 5.000 raccolte siti, si rischia di incorrere in tempi di inattività più estesi durante gli aggiornamenti. Se si prevede di superare le 5.000 raccolte siti, è consigliabile disporre di una chiara strategia di aggiornamento per fare fronte ai tempi di interruzione del servizio e agli effetti sulle operazioni e procurarsi ulteriore hardware per accelerare gli aggiornamenti del software e quelli che interessano i database. Per impostare il livello di avviso e il livello massimo relativi al numero di siti in un database del contenuto, utilizzare il cmdlet Set-SPContentDatabase di PowerShell con il parametro WarningSiteCount. Per altre informazioni, vedere Set-SPContentDatabase. |
Sottosistema di archiviazione RBS (Remote BLOB Storage, Archiviazione BLOB remoti) in NAS (Network Attached Storage, Archiviazione basata sulla rete) |
Nel 95% dei casi, i tempi per il primo byte di tutte le risposte provenienti da NAS non devono superare i 40 millisecondi. |
Limite |
Quando SharePoint Server 2016 viene configurato per l'utilizzo di RBS e gli oggetti BLOB risiedono nell'archiviazione NAS, considerare il seguente limite supportato. Dal momento in cui SharePoint Server 2016 richiede un oggetto BLOB al momento in cui riceve il primo byte da NAS, nel 95% dei casi non possono trascorrere più di 40 millisecondi. |
Limiti relativi alle raccolte siti
Nella tabella seguente sono riportate le linee guida consigliate per le raccolte siti.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Raccolte siti per farm |
250.000 per raccolta siti / 500.000 siti personali / 250.000 altri siti per farm. |
Supportato |
Il numero massimo di raccolte siti consigliato per ogni farm corrisponde a 500.000 siti personali più 250.000 siti basati su qualsiasi altro tipo di modello. I siti possono risiedere tutti in un'unica applicazione Web o possono essere distribuiti tra più applicazioni Web. Si noti che hanno effetto su questo limite altri fattori che possono ridurre il numero effettivo di raccolte siti che possono essere supportate da un database del contenuto specifico. Evitare pertanto di superare i limiti supportati quando un oggetto contenitore, ad esempio un database del contenuto, include un numero elevato di altri oggetti. Se ad esempio in una farm è contenuto un numero totale inferiore di database del contenuto, ognuno dei quali include un numero elevato di raccolte siti, è possibile che le prestazioni della farm subiscano ripercussioni negative molto prima che venga raggiunto il limite supportato per il numero di raccolte siti. Ad esempio, nella farm A è presente un'applicazione Web con 200 database del contenuto, ovvero una configurazione supportata. Se ognuno di questi database del contenuto include 1.000 raccolte siti, il numero totale di raccolte siti dell'applicazione Web sarà 200.000, valore che rientra nei limiti supportati. Se invece ogni database del contenuto include 10.000 raccolte siti, pur trattandosi di una quantità supportata per un database del contenuto, il numero totale di raccolte siti della farm raggiungerà 2.000.000, superando così il limite supportato di raccolte siti per applicazione Web. È consigliabile monitorare l'utilizzo della memoria nei server Web, in quanto dipende dai modelli di utilizzo e dal numero dei siti a cui viene effettuato l'accesso in un determinato intervallo di tempo. Allo stesso modo, anche le destinazioni della ricerca per indicizzazione possono presentare un sovraccarico della memoria. In tal caso, è opportuno configurare il pool di applicazioni per il riciclaggio prima che la quantità di memoria disponibile in qualsiasi server Web scenda al di sotto di 2 GB. |
Sito Web |
250.000 per raccolta siti / 250.000 per farm / 500.000 siti personali per farm. |
Supportato |
Il numero massimo consigliato di siti e siti secondari è 250.000. Le prestazioni possono diminuire quando il numero di siti secondari supera 2.000 a livello di raccolta siti. Importante Si consiglia di mantenersi al di sotto di 2.000 siti secondari per raccolta siti. È possibile creare un numero totale di dimensioni molto grande di siti Web mediante la creazione di più raccolte siti con un massimo di 2.000 siti Web per raccolta siti. Ad esempio, 125 raccolte siti che contengono 2.000 siti Web ciascuna compenseranno i 250.000 siti nella farm. Tuttavia, questo viene considerato il limite massimo consigliato per i siti non personali. Se si dispone di 250.000 raccolte di siti le quali contengono un sito Web radice diverso da quello del modello del sito personale, l'aggiunta di un sito secondario a uno qualsiasi di questi siti radice, comporta il superamento del limite dei siti Web impostato a 250.000. Se viene superato il limite consigliato di 2.000 siti per ogni raccolta siti, potrebbero verificarsi i problemi seguenti:
|
Dimensioni della raccolta siti |
Dimensione massima del database del contenuto |
Supportato |
Le dimensioni massime di una raccolta siti possono corrispondere al limite previsto per le dimensioni dei database del contenuto per lo scenario di utilizzo applicabile. Per altre informazioni sui diversi limiti previsti per le dimensioni dei database del contenuto in base a scenari di utilizzo specifici, vedere la tabella Limiti relativi ai database del contenuto in questo articolo. È consigliabile in genere limitare le dimensioni delle raccolte siti a 100 GB per i motivi seguenti:
|
Numero di canali dispositivi per raccolta siti di pubblicazione |
10 |
Limite |
Il numero massimo consentito di canali dispositivi per raccolta siti di pubblicazione è 10. |
Limiti relativi agli elenchi e alle raccolte
Nella tabella seguente sono riportate le linee guida consigliate per gli elenchi e le raccolte. Per ulteriori informazioni, vedere Progettazione di elenchi di grandi dimensioni e ottimizzazione delle prestazioni degli elenchi (SharePoint Server 2010).
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni delle righe degli elenchi |
8.000 byte per riga |
Limite |
Ogni elemento di elenco o di raccolta può occupare solo 8.000 byte in totale nel database. 300 byte sono riservati, pertanto restano 7.700 byte per le colonne degli utenti finali. Per i dettagli relativi alla quantità di spazio utilizzata dai singoli tipi di campo, vedere Limiti relativi alle colonne. |
Dimensioni dei file |
10 GB |
Statico |
La dimensione predefinita per i file è 2 GB (2.047 MB), ma un numero elevato di file di dimensioni particolarmente grandi può incidere sulle prestazioni della farm. |
Documenti |
30.000.000 per raccolta |
Supportato |
È possibile creare raccolte documenti molto grandi annidando le cartelle oppure utilizzando visualizzazioni standard e una gerarchia di siti. Questo valore può variare in base alla modalità di organizzazione dei documenti e delle cartelle e in base al tipo e alle dimensioni dei documenti archiviati. |
Versioni principali |
400,000 |
Supportato |
Se si supera questo limite, le operazioni di base relative ai file, quali ad esempio l'apertura o il salvataggio dei file, l'eliminazione e la visualizzazione della cronologia versioni, potrebbero avere esito negativo. |
Versioni secondarie |
511 |
Limite |
Il numero massimo di versioni secondarie consentito per i file è 511. Questo limite non può essere superato. |
Elementi |
30.000.000 per elenco |
Supportato |
È possibile creare elenchi molto estesi utilizzando visualizzazioni standard, gerarchie di siti e una struttura di spostamento nei metadati. Questo valore può variare in base al numero di colonne dell'elenco e all'utilizzo dell'elenco stesso. |
Operazioni in blocco |
100 elementi per operazione in blocco |
Limite |
L'interfaccia utente consente la selezione di un massimo di 100 elementi per le operazioni in blocco. |
Soglia ricerca visualizzazione elenco |
12 operazioni di join per query |
Soglia |
Specifica il numero massimo di join consentiti per query, ad esempio quelli basati sulle colonne di ricerca, utente/gruppo o stato del flusso di lavoro. Se nella query vengono utilizzati più di otto join, l'operazione verrà bloccata. Questa restrizione non si applica a operazioni con elementi singoli. Quando si utilizza la visualizzazione massima tramite il modello a oggetti (senza specificare tuttavia alcun campo della visualizzazione), in SharePoint vengono restituite al massimo le prime 12 ricerche. |
Soglia visualizzazione elenco |
maggiore di 5.000 |
Soglia |
Specifica il numero massimo di elementi di elenco o di raccolta che possono essere elaborati contemporaneamente da un'operazione di database, ad esempio una query, al di fuori dell'arco temporale giornaliero definito dall'amministratore in cui non vengono applicati limiti al numero di query. Quando si aggiunge o si rimuove un indice con colonne, la soglia è 20.000 per impostazione predefinita. Quando si elimina un elenco o una cartella, la soglia è 100.000 per impostazione predefinita. Quando si rinomina una cartella all'interno della stessa raccolta, la soglia è 100.000 per impostazione predefinita. |
Soglia visualizzazione elenco per controllori e amministratori |
20,000 |
Soglia |
Specifica il numero massimo di elementi di elenco o di raccolta che possono essere elaborati contemporaneamente da un'operazione di database, ad esempio una query, quando l'operazione viene eseguita da un controllore o da un amministratore con autorizzazioni appropriate. Questa impostazione è correlata a Ignora modello a oggetti. |
Siti secondari |
2.000 per visualizzazione sito |
Soglia |
L'interfaccia per enumerare i siti secondari di un determinato sito Web non funziona in modo ottimale quando il numero dei siti secondari è superiore a 2.000. Allo stesso modo, le prestazioni sia della pagina Tutto il contenuto del sito sia del controllo di visualizzazione ad albero peggioreranno in modo significativo man mano che aumenta il numero dei siti secondari. |
Elenco |
2.000 per sito Web |
Soglia |
Il test indica una riduzione delle prestazioni di visualizzazione elenco di oltre 2.000 voci. |
Creazione condivisa in Word e PowerPoint per file con estensione docx, pptx e ppsx |
10 redattori contemporaneamente per documento |
Soglia |
Il numero massimo consigliato di redattori simultanei è 10. Il limite statico è 99. Se vi sono 99 utenti che operano in modalità condivisa su un singolo documento aperto per modificarlo contemporaneamente, a qualsiasi utente successivo verrà visualizzato un errore "File in uso" e potrà soltanto aprire una copia di sola lettura. Con più di 10 utenti in modalità condivisa, si avrà gradualmente un'esperienza utente sempre meno ottimale, vi saranno più conflitti e agli utenti potrebbero essere necessarie più iterazioni per riuscire a caricare correttamente nel server le modifiche apportate. |
Ambito di sicurezza |
50.000 per elenco |
Soglia |
Gli ambiti di sicurezza univoci per un elenco non possono essere più di 50.000. Per la maggior parte delle farm, è consigliabile considerare la possibilità di abbassare tale limite a 5.000 ambiti univoci. Nel caso di elenchi di grandi dimensioni, optare eventualmente per una struttura in cui venga utilizzato il minor numero possibile di autorizzazioni esclusive. Quando il numero degli ambiti di sicurezza univoci per un elenco supera il valore della soglia della visualizzazione elenco (pari a 5.000 voci di elenco per impostazione predefinita), al momento di visualizzare l'elenco vengono eseguiti round trip di SQL Server aggiuntivi, condizione che può incidere negativamente sulle prestazioni di visualizzazione dell'elenco. Un ambito è un limite di sicurezza per un oggetto a protezione diretta e gli eventuali elementi foglio per cui non è definito un limite di sicurezza separato. Nell'ambito è incluso un elenco di controllo di accesso (ACL) ma, a differenza degli elenchi di controllo di accesso NTFS, possono essere incluse entità di sicurezza specifiche di SharePoint Server 2016. I membri di un elenco di controllo di accesso per un ambito possono includere utenti di Windows, account utente diversi da utenti di Windows (ad esempio account basati sui moduli) e gruppi di Active Directory o di SharePoint. |
Propagazione dell'ambito di sicurezza (ACL) |
500 oggetti figlio con ambiti univoci |
Soglia |
Il numero massimo di oggetti figlio con ambiti di sicurezza univoci che possono essere aggiornati durante la propagazione ACL non può superare il valore 500. Gli aggiornamenti ambito possono essere impostati per aggiornare gli oggetti figlio con la propagazione ACL, che aggiornerà esclusivamente gli elementi nell'ambito e gli elementi che ereditano autorizzazioni. Durante un aggiornamento dell'ambito padre che include propagazione ACL al figlio, se il numero massimo di oggetti figlio con ambiti univoci è maggiore di 500, la propagazione non riuscirà solo con alcuni oggetti figlio con ambiti univoci potenzialmente aggiornati. Se il numero massimo di oggetti figlio con ambiti di sicurezza univoci è superiore a 500, non utilizzare la propagazione ACL. |
Limiti relativi alle colonne
I dati di SharePoint Server 2016 vengono archiviati in tabelle di SQL Server.
Per ogni tipo di colonna viene indicato un valore che rappresenta le dimensioni in byte. La somma di tutte le colonne di un elenco di SharePoint non può superare 8.000. Quando vengono create colonne di tipi diversi nello stesso elenco, gli utenti possono raggiungere il limite di 8.000 byte prima di raggiungere il numero massimo per uno dei tipi.
| Limite | Valore massimo | Tipo di limite | Dimensioni per colonna | Note |
|---|---|---|---|---|
Una riga di testo |
255 |
Soglia |
30 byte |
|
Più righe di testo |
350 |
Soglia |
22 byte |
|
Scelta |
255 |
Soglia |
30 byte |
|
Scelta (selezione multipla) |
350 |
Soglia |
22 byte |
|
Numero |
550 |
Soglia |
14 byte |
|
Valuta |
550 |
Soglia |
14 byte |
|
Data e ora |
550 |
Soglia |
14 byte |
|
Ricerca |
750 |
Soglia |
10 byte |
|
Sì/No |
1000 |
Soglia |
7 byte |
|
Utente o gruppo |
750 |
Soglia |
10 byte |
|
Collegamento ipertestuale o immagine |
127 |
Soglia |
60 byte |
Una colonna Collegamento ipertestuale o Immagine ha due colonne per l'archiviazione: una per l'URL e una per la descrizione. |
Calcolato |
255 |
Soglia |
30 byte |
Il ritorno a capo automatico delle righe di SQL Server viene eseguito ogni 8 colonne di un elenco di SharePoint. Il valore predefinito pari a 6 consente un massimo di 48 colonne calcolate per ogni elenco di SharePoint (6 * 8 = 48). |
GUID |
350 |
Soglia |
22 byte |
Il ritorno a capo automatico delle righe di SQL Server viene eseguito dopo ogni colonna di un elenco di SharePoint. Il valore predefinito pari a 6 consente un massimo di 6 colonne GUID per ogni elenco di SharePoint (6 * 1 = 6). |
Intero |
750 |
Soglia |
10 byte |
|
Metadati gestiti |
190 |
Soglia |
60 byte per il primo campo, 40 byte per ognuno dei successivi |
Per il primo campo Metadati gestiti aggiunto a un elenco vengono allocate quattro colonne:
Per ogni campo Metadati gestiti successivo aggiunto a un elenco vengono aggiunte altre due colonne:
Il numero massimo di colonne di metadati gestiti viene calcolato come (14 + (16 * (n-1))), dove è il valore di mapping delle righe (il valore predefinito è 6). |
Georilevazione |
2 |
Soglia |
30 byte |
Le colonne di dati esterni si basano sul concetto di una colonna principale con colonne secondarie. Quando si aggiunge una colonna di dati esterni, è possibile selezionare alcuni campi secondari del tipo di contenuto esterno che si desidera aggiungere all'elenco. Ad esempio, nel caso di un tipo di contenuto esterno “Cliente” con campi come “ID”, “Nome”, “Nazione” e “Descrizione”, quando si aggiunge una colonna di dati esterni di tipo “Cliente” a un elenco, è possibile aggiungere campi secondari per visualizzare l'“ID”, il “Nome” e la “Descrizione” del cliente. Complessivamente queste sono le colonne che vengono aggiunte:
Colonna principale: un campo di testo.
Colonna ID nascosta: un campo di testo con più righe.
Colonne secondarie: ogni colonna secondaria è un testo, un numero, un valore booleano o un testo su più righe basato sul tipo di dati della colonna secondaria secondo quanto definito nel modello del Catalogo dati business. L'ID ad esempio potrebbe essere associato a una colonna di tipo Numero, il nome potrebbe essere associato a una colonna di tipo Una riga di testo e la descrizione potrebbe essere mappata a una colonna di tipo Più righe di testo.
Limiti relativi alle pagine
Nella tabella seguente sono riportate le linee guida consigliate per le pagine.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Web part |
25 per pagina web part o wiki |
Soglia |
Questo valore è una stima basata su web part semplici. La complessità delle web part determina infatti quante è possibile utilizzarne in una pagina prima di avere ripercussioni negative sulle prestazioni. |
Limiti relativi alla sicurezza
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Numero di gruppi di SharePoint a cui può appartenere un utente |
5,000 |
Supportato |
Non si tratta di un limite rigido, ma è coerente con le linee guida di Active Directory. Su tale valore influiscono diversi aspetti:
|
Utenti in una raccolta siti |
2 milioni per raccolta siti |
Supportato |
È possibile aggiungere milioni di utenti al sito Web utilizzando gruppi di sicurezza di Microsoft Windows per gestire la sicurezza anziché utenti singoli. Questo limite è basato sulla gestibilità e sulla facilità di spostamento all'interno dell'interfaccia utente. Quando nella raccolta siti sono presenti numerosi (più di mille) elementi (gruppi di sicurezza di utenti), per gestire gli utenti è consigliabile utilizzare PowerShell anziché l'interfaccia utente. In questo modo sarà più semplice eseguire le attività di gestione. |
Utenti/entità di Active Directory in un gruppo di SharePoint |
5.000 per gruppo di SharePoint |
Supportato |
SharePoint Server 2016 consente di aggiungere utenti o gruppi di Active Directory a un gruppo di SharePoint. L'utilizzo di un massimo di 5.000 utenti (oppure di utenti o gruppi di Active Directory) in un gruppo di SharePoint garantisce prestazioni accettabili. Tale limite incide soprattutto sulle attività seguenti:
|
Gruppi di SharePoint |
10.000 per raccolta siti |
Supportato |
Oltre i 10.000 gruppi, aumenta in modo significativo il tempo necessario per eseguire le diverse operazioni, in particolare per l'aggiunta di un utente a un gruppo esistente, la creazione di un nuovo gruppo e il rendering delle visualizzazioni gruppo. |
Entità di sicurezza: dimensioni dell'ambito di sicurezza |
5.000 per elenco di controllo di accesso |
Supportato |
Le dimensioni dell'ambito incidono sui dati utilizzati per il calcolo di un controllo di sicurezza. Tale calcolo viene eseguito ogni volta che cambia l'ambito. Non si tratta di un limite rigido, ma più è esteso l'ambito, più sarà lungo il calcolo. |
Limiti in base alla funzionalità
In questa sezione i limiti sono ordinati in base alla funzionalità.
Limiti relativi alla ricerca
Le linee guida consigliate per la ricerca sono organizzate in base agli aspetti della ricerca su cui incidono, ovvero la topologia, le dimensioni degli elementi, i dizionari, la ricerca per indicizzazione, lo schema, le query e i risultati, la classificazione e l'indice.
Ricerca: limiti relativi alla topologia
I limiti relativi alla topologia garantiscono una comunicazione efficiente tra i componenti di ricerca. Se si superano questi limiti, tale comunicazione si rallenta, causando eventualmente latenze più lunghe per le query e infine l'interruzione della ricerca.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Componenti di elaborazione dell'analisi |
6 per applicazione del servizio di ricerca, 1 per server |
Supportato |
|
Database di report di analisi |
4 per applicazione del servizio di ricerca |
Soglia |
È possibile superare questo limite per soddisfare requisiti specifici. Durante l'implementazione della scalabilità, aggiungere un database di report di analisi quando la dimensione totale di uno qualsiasi dei database di analisi distribuiti raggiunge 250 GB oppure 20 milioni di righe. In questo modo il ripartizionamento è bilanciato in modo ottimale. |
Database dei collegamenti |
4 per applicazione del servizio di ricerca |
Supportato |
Il maggior numero testato di elementi che un database dei collegamenti può includere è 100 milioni. |
Componenti di ricerca per indicizzazione |
16 per applicazione del servizio di ricerca, 1 per server |
Supportato |
|
Componenti di indicizzazione |
60 per applicazione del servizio di ricerca, quattro per server |
Supportato |
Per calcolare il numero di componenti di indicizzazione di cui si dispone, moltiplicare il numero di partizioni di indice per il numero delle repliche di indice. |
Partizioni di indice |
25 per applicazione del servizio di ricerca |
Supportato |
In una partizione di indice è presente un sottoinsieme dell'indice dell'applicazione del servizio di ricerca. Aumentando il numero delle partizioni di indice, ognuna di tali partizioni conterrà un sottoinsieme più limitato dell'indice, con una conseguente riduzione della quantità di RAM e di spazio su disco necessaria nei server che ospitano i componenti di indicizzazione. |
Repliche di indice |
3 per partizione di indice |
Supportato |
Ogni partizione di indice può disporre di un set di repliche. Se si aumenta il numero delle repliche di indice, vi sarà un miglioramento delle prestazioni delle query e della tolleranza di errore. Se però si aggiungono troppe repliche alla partizione di indice, l'indicizzazione ne può risentire. Per gli scenari di siti Internet, che in genere hanno una frequenza di query elevata ma un volume di contenuti limitato (meno di 4 milioni di elementi per partizione), il limite supportato è di 6 repliche di indice per partizione. |
Componenti di elaborazione del contenuto |
1 per server |
Supportato |
La topologia di ricerca supporta la scalabilità orizzontale per il numero di componenti di elaborazione del contenuto. Benché un host fisico o una macchina virtuale specifica supporti più componenti di elaborazione del contenuto, è possibile sfruttare meglio la capacità della CPU utilizzando un unico componente di questo tipo. Ciò è dovuto al fatto che un meccanismo incorporato ottimizza l'utilizzo della CPU modificando il numero delle sessioni di feeding in base ai core di CPU disponibili. Più sessioni di feeding consentono al componente di elaborazione del contenuto di elaborare in parallelo i documenti in ingresso. Questo meccanismo presuppone l'uso di un unico componente di elaborazione del contenuto per ogni host. Se il numero dei core fisici nell'host è uguale a N, il componente di elaborazione del contenuto disporrà di N*K sessioni di feeding. K è un coefficiente costante con valore iniziale pari a 3. Un server 4 core disporrà di 12 sessioni di feeding, pertanto il componente di elaborazione del contenuto potrà elaborare 12 documenti in parallelo. È possibile modificare il valore di K impostando la proprietà NumberOfCssFeedersPerCPUForRegularCrawl dell'applicazione del servizio di ricerca. SharePoint Server 2016 limita il valore di N a un massimo di 12, anche se un server dispone di più di 12 core fisici. Un server a 16 core disporrà quindi di N*K = 12 * 3 = 36 sessioni di feeding. Nel caso vi sia ancora tempo di inattività della CPU, considerare la possibilità di aumentare il coefficiente K invece di aggiungere un altro componente di elaborazione del contenuto. Se si aumenta il coefficiente K, sarà necessario verificare che l'host disponga di memoria sufficiente. |
Componenti di elaborazione delle query |
Uno per server |
Supportato |
SharePoint Server 2016 supporta solo un componente di elaborazione delle query per ogni computer fisico o macchina virtuale. |
Componenti di ricerca |
64 per applicazione del servizio di ricerca |
Supportato |
Questo limite non include i componenti di ricerca per indicizzazione. La somma di tutti gli altri componenti di ricerca deve rispettare questo limite. |
Applicazioni del servizio di ricerca |
20 per farm |
Supportato |
Nella stessa farm è possibile distribuire più applicazioni del servizio di ricerca perché i database e i componenti di ricerca possono essere assegnati a server separati. Questo limite è inferiore al limite relativo al numero totale delle applicazioni di servizio all'interno di una farm. |
Origine di contenuto |
500 per applicazione del servizio di ricerca |
Limite |
A ogni origine di contenuti è associato un sovraccarico; pertanto, si consiglia di creare il minor numero possibile di origini di contenuti per soddisfare gli altri requisiti operativi, ad esempio le differenze di pianificazione e priorità per le ricerche di indicizzazione. |
Ricerca: limiti relativi alle dimensioni degli elementi
I limiti relativi alle dimensioni degli elementi hanno la funzione di salvaguardare le prestazioni della ricerca per indicizzazione e la dimensione dell'indice. Di seguito sono riportati alcuni esempi del modo in cui i limiti possono incidere sulla ricerca:
Se non si ottengono risultati quando si ricerca un elemento, è possibile che l'elemento sia troppo grande. Nel log di ricerca per indicizzazione verrà visualizzato un avviso che indica che il file ha superato la dimensione massima che il crawler può scaricare.
Se si ricerca un testo in un elemento e si ottengono risultati solo per la prima parte del testo, è possibile che il componente di elaborazione del contenuto abbia troncato l'elemento perché superava alcuni dei limiti di dimensione previsti. Quando tale componente tronca un elemento, indica questa condizione impostando la proprietà gestita IsPartiallyProcessed su True. Nel log di ricerca per indicizzazione verrà inoltre visualizzato un avviso che indica il motivo del troncamento.
Se si ottimizzano i limiti relativi alle dimensioni degli elementi, è consigliabile gestirli nell'ordine in cui sono riportati in questa tabella.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni dei documenti che il componente di ricerca per indicizzazione può scaricare |
64 MB (3 MB per documenti di Excel) |
Soglia |
La ricerca scarica i metadati e il contenuto da un documento finché non raggiunge le dimensioni massime previste. Il resto del contenuto non viene scaricato, mentre i metadati del documento vengono sempre scaricati. È possibile modificare il limite predefinito per le dimensioni massime del documento. È possibile effettuare questa operazione utilizzando i cmdlet Microsoft PowerShell che consentono di modificare la proprietà MaxDownLoadSize o MaxDownloadSizeExcel dell'applicazione del servizio di ricerca. La proprietà MaxDownLoadSize non influisce sulla dimensione massima dei documenti Excel. Immettere il volume in megabyte. Il valore relativo alle dimensioni massime del documento corrisponde a 1024 MB (anche per i documenti Excel). Se si aumenta il limite relativo alle dimensioni massime dei documenti, la ricerca indicizza più contenuto e richiede più spazio su disco. |
Dimensioni del contenuto analizzato |
2 milioni di caratteri |
Limite |
La ricerca interrompe l'analisi di un elemento dopo che ha analizzato un massimo di 2 milioni di caratteri del relativo contenuto, inclusi gli allegati dell'elemento. La quantità effettiva di caratteri analizzati può essere inferiore a questo limite perché la ricerca impiega al massimo 30 secondi per analizzare un singolo elemento e i relativi allegati. Quando la ricerca smette di analizzare un elemento, questo viene contrassegnato come elaborato parzialmente. Il contenuto non analizzato non viene elaborato e pertanto non viene indicizzato. |
Caratteri prodotti dal word breaker |
1,000,000 |
Limite |
La ricerca scompone il contenuto in parole singole (token). Può perciò produrre fino a 1.000.000 di caratteri di un unico elemento, inclusi i relativi allegati. La quantità effettiva di elementi elaborati può essere inferiore a questo limite perché la ricerca impiega al massimo 30 secondi per eseguire la scomposizione in parole. Il contenuto restante non viene elaborato e pertanto non viene indicizzato. |
Dimensioni delle proprietà gestite indicizzate |
512 KB per proprietà gestita disponibile per la ricerca/disponibile per query |
Soglia |
Si tratta del valore predefinito relativo alla dimensione massima di una proprietà gestita che viene impostata su "ricerca consentita" o su "disponibile per query". È possibile configurare questo limite utilizzando i cmdlet PowerShell e il modello di oggetti dello schema al fine di impostare l'attributo MP.MaxCharactersInPropertyStoreIndex. Immettere il valore in byte. Il valore per questa dimensione massima è di 2097152 byte. Se si aumenta tale limite, si attiva l'indicizzazione di più dati per la proprietà gestita. L'indicizzazione di un numero maggiore di dati per proprietà gestita utilizza più spazio del disco e aumenta il carico generale del sistema di ricerca. |
Dimensioni delle proprietà gestite recuperabili |
16 KB per proprietà gestita |
Soglia |
Questo è il valore predefinito per la dimensione massima di una proprietà gestita recuperabile. Se si aumenta questo limite, si consente l'indicizzazione di una quantità maggiore di dati per ogni proprietà gestita, nonché il recupero di più dati per ogni proprietà gestita per i risultati di ricerca, con un conseguente aumento del carico globale sul sistema e della quantità di spazio su disco utilizzata. È possibile configurare questo limite per proprietà gestita utilizzando i cmdlet PowerShell e il modello di oggetti dello schema al fine di impostare l'attributo P.MaxCharactersInPropertyStoreForRetrieval. Immettere il valore in byte. Il valore per questa dimensione massima è di 2097152 byte. Se si aumenta tale limite, si attiva l'indicizzazione di più dati per la proprietà gestita. L'aumento di questo limite consente anche alla funzionalità di ricerca di recuperare più dati per proprietà gestita relativi ai risultati di ricerca. Indicizzazione e recupero di più dati per proprietà gestita |
Dimensioni delle proprietà gestite ordinabili e per affinamento ricerca |
16 KB per proprietà gestita |
Limite |
Questa è la dimensione massima di una proprietà gestita ordinabile e per affinamento ricerca. |
Dimensioni dei token |
Variabile |
Limite |
La ricerca può indicizzare token di qualsiasi lunghezza, ma il word breaker utilizzato per produrre i token può limitare tale lunghezza. I word breaker sono componenti che riconoscono la lingua e che scompongono il contenuto in parole singole (token appunto). È inoltre possibile creare word breaker personalizzati. Il limite relativo alle dimensioni dei token dipende pertanto dal word breaker. Di seguito è riportato il limite del word breaker per le lingue occidentali:
|
Ricerca: limiti relativi ai dizionari
I limiti relativi ai dizionari hanno la funzione di salvaguardare la memoria, l'efficienza nell'elaborazione del contenuto e i risultati delle query.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Numero di voci in un Thesaurus |
1 milione |
Supportato |
Il thesaurus include i sinonimi per i termini di query. Se si supera questo limite testato, possono verificarsi un maggior utilizzo della memoria e tempi di risposta alle query più lunghi. |
Numero di voci in un dizionario personalizzato per l'estrazione di entità |
1 milione |
Supportato |
Se si supera questo limite testato, possono verificarsi un maggior utilizzo della memoria, un rallentamento dell'indicizzazione e tempi di risposta alle query più lunghi. |
Numero di voci in un dizionario di ricerca personalizzato |
5.000 termini per tenant |
Limite |
Questo è il limite relativo al numero di termini consentiti per i dizionari di inclusione ed esclusione per la correzione degli errori di ortografia delle query e per l'estrazione delle società. È possibile archiviare un numero di termini superiore a questo limite nell'archivio termini, ma la ricerca utilizza solo 5000 termini per ogni tenant. |
Ricerca: limiti relativi allo schema
I limiti relativi allo schema hanno la funzione di salvaguardare le risorse di memoria e di mantenere il sovraccarico per le operazioni di gestione a un livello accettabile.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Proprietà sottoposte a ricerca per indicizzazione |
500.000 per applicazione del servizio di ricerca |
Supportato |
Il contenuto e i metadati degli elementi sottoposti a ricerca per indicizzazione sono rappresentati come proprietà sottoposte a ricerca per indicizzazione. È possibile mappare queste proprietà sottoposte a ricerca per indicizzazione a proprietà gestite. Se il numero delle proprietà sottoposte a ricerca per indicizzazione supera questo limite supportato, la velocità di indicizzazione diminuisce. |
Proprietà gestite |
50.000 per applicazione del servizio di ricerca |
Supportato |
Per la ricerca, nelle query vengono utilizzate proprietà gestite. Le proprietà sottoposte a ricerca per indicizzazione sono mappate alle proprietà gestite. Quando si supera il limite supportato per le proprietà gestite, la velocità di indicizzazione diminuisce. |
Mapping delle proprietà gestite |
100 per proprietà gestita |
Supportato |
Le proprietà sottoposte a ricerca per indicizzazione possono essere mappate alle proprietà gestite. Superando tale limite, potrebbe diminuire la velocità della ricerca per indicizzazione e possono calare le prestazioni delle query. |
Valori per proprietà gestita |
1,000 |
Statico |
Una proprietà gestita può disporre di più valori dello stesso tipo. Questo è il numero massimo di valori consentito per proprietà gestita multivalore per ogni documento. Se questo numero viene superato, i valori restanti vengono eliminati. |
Proprietà dei metadati riconosciute |
100.000 per elemento sottoposto a ricerca per indicizzazione |
Supportato |
Questo è il numero massimo di proprietà dei metadati che il componente di ricerca per indicizzazione può determinare durante l'esecuzione di questo tipo di ricerca per un elemento. Queste proprietà possono essere mappate o utilizzate per le query. Se ci si avvicina a questo numero di proprietà sottoposte a ricerca per indicizzazione, la velocità di tale ricerca potrebbe diminuire. |
Ricerca: limiti relativi alla ricerca per indicizzazione
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Indirizzi iniziali |
500 per origine contenuto |
Supportato |
|
Lunghezza del nome host del computer |
15 caratteri |
Soglia |
Il NetBIOS limita la lunghezza massima del nome host del computer a questo valore. |
Database di ricerca per indicizzazione |
15 per applicazione del servizio di ricerca |
Supportato |
Ricerca: limiti relativi alle query e ai risultati
I limiti relativi alle query e ai risultati hanno la funzione di salvaguardare il motore di ricerca dall'esecuzione di espressioni di query molto estese e dalla restituzione di set di risultati di grandi dimensioni. In questo modo, si evitano attacchi Denial of Service (DoS) e si garantisce una restituzione puntuale dei risultati. Se è necessario recuperare più risultati, è consigliabile utilizzare il paging.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Lunghezza del testo per le query che utilizzano il linguaggio Keyword Query Language |
4 KB (4.096 caratteri) |
Supportato |
Questo è il valore testato e predefinito per la lunghezza massima del testo per una query creata con il linguaggio KQL (Keyword Query Language), tranne per le query di individuazione. Per tali query, il valore massimo predefinito è 16 KB (16.384 caratteri). Il valore predefinito per la lunghezza massima del testo può essere aumentato fino al limite statico di 20 KB (20.480) per tutti i tipi di query. |
Numero di righe in un set di risultati |
500 righe |
Supportato |
Questo è il valore testato e predefinito per il numero massimo di righe in un set di risultati, tranne per le query di individuazione. Per tali query, il valore predefinito è 10.000 righe. Per visualizzare l'intero set di risultati, eseguire più query di paging. È possibile modificare il valore relativo al numero massimo di righe in un set di risultati utilizzando i cmdlet di PowerShell per modificare la proprietà MaxRowLimit dell'applicazione del servizio di ricerca. MaxRowLimit definisce il valore massimo della proprietà RowLimit per le query e della proprietà RowLimit per le query di individuazione. RowLimit definisce il numero di righe incluse in ogni pagina di un set di risultati. È possibile aumentare MaxRowLimit fino a 10.000 righe, che è un limite supportato. |
Rimozione dei risultati |
Nessun limite |
Supportato |
|
Quota degli avvisi di ricerca |
100.000 avvisi per applicazione del servizio di ricerca |
Supportato |
Gli utenti finali possono impostare avvisi di ricerca per il set di risultati di una query. Quando i risultati vengono modificati o aggiornati, la ricerca invia una notifica all'utente finale. Questo è il limite testato per un'applicazione del servizio di ricerca con una combinazione di query degli utenti finali (75%) e query di avviso (25%). Il limite per un'applicazione del servizio di ricerca che dispone solo di query di avviso corrisponde a 400.000 avvisi. Questi limiti si basano su un sistema con cinque query al secondo (QPS). |
Ricerca: limiti relativi alla classificazione
I limiti relativi alla classificazione hanno la funzione di salvaguardare la memoria del server applicazioni, la latenza delle query e le dimensioni dell'indice.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Modelli di classificazione |
1.000 per tenant |
Limite |
Se ci si avvicina a questo limite, si possono avere effetti negativi sulle prestazioni globali del sistema. |
Contesti univoci utilizzati per la classificazione |
15 contesti univoci per modello di classificazione |
Limite |
Questo è il numero massimo di contesti univoci per ogni modello di classificazione. |
Pagine rilevanti |
1 pagina di livello principale e il minimo di pagine di secondo e terzo livello per applicazione del servizio di ricerca |
Supportato |
Usare il minor numero possibile di pagine di secondo e terzo livello per ottenere comunque la pertinenza desiderata. Il limite statico è 200 pagine rilevanti per livello di pertinenza per applicazione di ricerca. Se si aggiungono ulteriori pagine si potrebbe non ottenere la pertinenza desiderata. Aggiungere il sito chiave al primo livello di pertinenza. Aggiungere altri siti chiave al secondo o al terzo livello di pertinenza, uno alla volta. Valutare la pertinenza dopo ogni aggiunta per essere certi di raggiungere l'effetto desiderato. |
Ricerca: limiti relativi all'indice
I limiti relativi all'indice hanno la funzione di salvaguardare l'indice da un'espansione eccessiva e dal superamento delle risorse disponibili.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Termini univoci nell'indice |
2^31 (>2 miliardi di termini) |
Limite |
Questo è il numero massimo di termini univoci che possono essere presenti nell'indice di un'applicazione del servizio di ricerca. |
Indici full-text definiti dall'utente |
10 |
Limite |
Questo è il numero massimo di indici full-text. |
Elementi indicizzati |
20 milioni per partizione di indice |
Supportato |
In ogni partizione di indice è incluso un sottoinsieme dell'intero indice di ricerca. Se il numero degli elementi indicizzati è elevato rispetto alla quantità di memoria disponibile nel server, i tempi di risposta alle query si estenderanno. |
Limiti relativi al servizio profili utente
Nella tabella seguente sono riportate le linee guida consigliate per il servizio profili utente.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Profili utente |
2.000.000 per applicazione di servizio |
Supportato |
Un'applicazione di servizio profili utente può supportare fino a 2 milioni di profili utente con funzionalità di social networking complete. Tale numero rappresenta il numero di profili che è possibile importare nell'archivio dei profili utente da un servizio directory, nonché il numero di profili che un'applicazione di servizio profili utente può supportare senza influire negativamente sulle prestazioni delle funzionalità di social networking. |
Tag di social networking, note e valutazioni |
500.000.000 per database di social networking |
Supportato |
In un database di social networking è supportato al massimo un totale di 500 milioni tra tag di social networking, note e valutazioni senza ripercussioni significative sulle prestazioni. Le operazioni di manutenzione dei database, ad esempio il backup e il ripristino, potrebbero tuttavia risultare più lente. |
Limiti relativi alla distribuzione del contenuto
Nella tabella seguente sono riportate le linee guida consigliate per la distribuzione del contenuto.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Processi di distribuzione del contenuto in esecuzione in percorsi diversi |
20 |
Supportato |
Per i processi eseguiti contemporaneamente in percorsi connessi a raccolte siti nello stesso database del contenuto di origine, vi un rischio maggiore di situazioni di deadlock per il database. Per i processi che devono essere eseguiti tutti contemporaneamente, è consigliabile spostare le raccolte siti in database del contenuto di origine diversi. Nota Non sono possibili processi eseguiti contemporaneamente nello stesso percorso. Se si utilizzano snapshot di SQL Server per la distribuzione del contenuto, ogni percorso genera uno snapshot. Tale situazione comporta requisiti di I/O maggiori per il database di origine. Per altre informazioni, vedere Informazioni sui percorsi e i processi di distribuzione. |
Limiti relativi ai blog
Nella tabella seguente sono riportate le linee guida consigliate per i blog.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Post di blog |
5.000 per sito |
Supportato |
Il numero massimo consentito di post di blog è 5.000 per sito. |
Commenti |
1.000 per post |
Supportato |
Il numero massimo consentito di commenti è 1.000 per post. |
Limiti relativi a Servizi di integrazione applicativa
Nella tabella seguente sono riportate le linee guida consigliate per Servizi di integrazione applicativa.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Tipi di contenuto esterno (in memoria) |
5.000 per server Web (per tenant) |
Limite |
Numero totale di definizioni del tipo di contenuto esterno caricate in memoria in un determinato momento in un server Web. |
Connessioni a sistemi esterni |
500 per server Web |
Limite |
Numero di connessioni a sistemi esterni attive/aperte in un determinato momento. Il valore massimo predefinito è 200 e il limite statico è 500. Tale limite viene applicato all'ambito del server Web, indipendentemente dal tipo di sistema esterno, ad esempio database, assembly .NET e così via. Il valore massimo predefinito viene utilizzato per limitare il numero delle connessioni. Un'applicazione può specificare un limite superiore tramite il contesto di esecuzione e il limite statico applica il valore massimo anche per le applicazioni che non rispettano il valore predefinito. |
Elementi di database restituiti per richiesta |
2.000 per connettore di database |
Soglia |
Numero di elementi per richiesta che il connettore di database può restituire. Il valore massimo predefinito pari a 2.000 viene utilizzato dal connettore di database per limitare il numero di risultati che possono essere restituiti per pagina. L'applicazione può specificare un limite superiore tramite il contesto di esecuzione e il massimo assoluto applica il valore massimo anche per le applicazioni che non rispettano il valore predefinito. Il limite statico è 1.000.000. |
Latenza della risposta |
600 secondi |
Soglia |
Timeout utilizzato dal connettore dati esterno per ogni richiesta. Il valore predefinito è 180 secondi, ma le applicazioni possono essere configurate in modo da specificare un valore superiore, fino a un massimo di 600 secondi. |
Dimensioni delle risposte di servizio |
150.000.000 byte |
Soglia |
Questo è il volume massimo di dati per ogni richiesta che il connettore dati esterno può restituire. Il valore predefinito è 3.000.000 byte, ma le applicazioni possono essere configurate in modo da specificare un valore superiore, fino a un massimo di 150.000.000 byte. |
Descrittore di filtro (in archivio) |
200 per metodo del tipo di contenuto esterno |
Limite |
Il numero massimo di descrittori di filtro per ogni metodo relativo al tipo di contenuto esterno è 200. |
Identificatore del tipo di contenuto esterno (in archivio) |
20 per tipo di contenuto esterno |
Limite |
Il numero massimo consentito di identificatori per ogni tipo di contenuto esterno è 20. |
Elemento di database |
1.000.000 per richiesta |
Soglia |
Il numero massimo predefinito di elementi per richiesta che il connettore di database può restituire è 2.000, mentre il massimo assoluto è 1.000.000. Il valore massimo predefinito viene utilizzato dal connettore di database per limitare il numero di risultati che possono essere restituiti per pagina. L'applicazione può specificare un limite superiore tramite il contesto di esecuzione e il massimo assoluto applica il valore massimo consentito anche per le applicazioni che non rispettano il valore predefinito, ad esempio come nel caso dell'indicizzazione. |
Limiti relativi ai flussi di lavoro
Nella tabella seguente sono riportate le linee guida consigliate per il flusso di lavoro.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Soglia di posticipazione dei flussi di lavoro |
15 |
Soglia |
15 è il numero massimo di flussi di lavoro che possono essere eseguiti contemporaneamente su un database del contenuto, escludendo le istanze in esecuzione nel servizio timer. Quando viene raggiunta tale soglia, le nuove richieste di attivazione di flussi di lavoro vengono accodate in modo da essere eseguite successivamente dal relativo servizio timer. Man mano che viene completata l'esecuzione senza servizio timer, le nuove richieste vengono conteggiate in relazione a questa soglia. Tale limite può essere configurato utilizzando il cmdlet Set-SPFarmConfig di PowerShell. Per altre informazioni, vedere Set-SPFarmConfig. Nota: questo limite non si riferisce al numero totale di istanze di flusso di lavoro che possono essere in esecuzione. Si tratta invece del numero di istanze in fase di elaborazione. Aumentando tale limite, aumenta la velocità effettiva per l'avvio e il completamento di attività relative al flusso di lavoro, ma aumenta anche il carico del database del contenuto e delle risorse di sistema. |
Dimensioni blocco timer flusso di lavoro |
100 |
Soglia |
Numero di eventi che verranno raccolti e forniti ai flussi di lavoro da ogni esecuzione del processo timer flussi di lavoro. Può essere configurato utilizzando PowerShell. Per consentire ulteriori eventi, è possibile eseguire istanze aggiuntive del servizio timer flussi di lavoro di SharePoint Foundation. |
Associazioni di flusso di lavoro |
100 per elenco |
Supportato |
Se si supera questo limite, le prestazioni del browser ne risentiranno a causa dell'elevato volume di dati che viene caricato per più di 100 associazioni e le relative colonne di stato. |
Voci di elenco o documenti che possono essere creati o caricati in blocco per avviare le istanze di flusso di lavoro |
5.000 elementi |
Supportato |
Mediante i test è stato verificato che tutti gli eventi di attivazione dei flussi di lavoro vengono elaborati per un'associazione di flusso di lavoro al momento della creazione dell'elemento quando vengono creati fino a 5.000 elementi con un unico caricamento in blocco. Se si supera questo limite, può verificarsi un timeout dell'avvio del flusso di lavoro. |
Definizioni di flusso di lavoro pubblicate per sito Web |
1.000 per sito Web |
Supportato |
Il numero massimo supportato di definizioni di flusso di lavoro pubblicate per ogni sito Web è 1.000. |
Associazioni di flusso di lavoro totali per sito |
1.799 per sito |
Limite |
Il bus di servizio supporta un massimo di 1.799 sottoscrizioni per ogni ambito. Tale valore massimo include la somma delle associazioni pubblicate e non pubblicate. |
Dimensioni massime delle definizioni di flusso di lavoro (XAML) |
5.120 KB |
Limite |
I tentativi di pubblicare file XAML che superano tali dimensioni avranno esito negativo. |
Profondità massima di un passaggio secondario dei flussi di lavoro in XAML (complessità dei flussi di lavoro) |
121 livelli |
Limite |
È previsto un limite massimo di 125 per la profondità dei nodi in XAML. 121 come valore massimo viene applicato per le attività predefinite, quali gestione temporanea, sequenziazione e così via, inserite automaticamente da SharePoint Designer. |
Attivazioni di istanze di flusso di lavoro al secondo per server Web |
6 al secondo |
Soglia |
I test hanno confermato che un server Web SharePoint può attivare un massimo di 6 istanze di flusso di lavoro al secondo. Questo numero è cumulativo, pertanto varia in base al numero di server Web presenti nella farm. Ad esempio, 2 server Web possono attivare 12 istanze di flusso di lavoro al secondo, mentre 3 server Web possono attivarne 18. |
Chiamate REST dal flusso di lavoro di SharePoint al secondo per server Web |
60 al secondo |
Supportato |
I test hanno confermato che un server Web SharePoint può elaborare efficacemente fino a 60 chiamate REST al secondo dal flusso di lavoro di SharePoint. Se questo volume viene superato, è consigliabile aggiungere alla farm di SharePoint un altro server Web con bilanciamento del carico. Durante il testing, 120 chiamate REST al secondo su un solo server Web hanno determinato un elevato utilizzo della CPU, pari al 90-100%. Aggiungendo un secondo server Web, l'utilizzo della CPU è sceso al 30-40% su entrambi i server. Aggiungendo un terzo server Web, è stato possibile elaborare 180 chiamate al secondo con un utilizzo della CPU pari al 30-40% su tutti e tre i server e così via. I server utilizzati per questo test erano macchine virtuali Hyper-V, ognuna con un processore 16 core e 24 GB di RAM. |
Dimensioni dei valori delle variabili dei flussi di lavoro |
256 KB |
Limite |
La quantità massima di dati che può essere archiviata in un'unica variabile di flusso di lavoro è pari a 256 KB. Se si supera questo limite, l'istanza di flusso di lavoro viene terminata. |
Dimensioni massime degli elenchi per le ricerche dei flussi di lavoro in campi non indicizzati |
5.000 voci per visualizzazione elenco |
Soglia |
Questo limite è il risultato del limite massimo relativo alle dimensioni della visualizzazione. Quando tale limite viene superato, le ricerche dei flussi di lavoro in campi non indicizzati hanno esito negativo per gli utenti senza privilegi di amministratore. A questa soglia è possibile creare un indice per il campo, in modo che i flussi di lavoro possano eseguire correttamente le ricerche basate sul campo in questione. |
Dimensioni massime degli elenchi per le associazioni di flusso di lavoro ad avvio automatico |
10 milioni di voci per elenco |
Supportato |
I test hanno confermato che non vi sono ripercussioni sulle prestazioni delle associazioni di flusso di lavoro ad avvio automatico quando le dimensioni degli elenchi raggiungono 1 milione di voci. Poiché il tempo di risposta resta invariato mentre le dimensioni degli elenchi cambiano, il limite effettivo corrisponde al numero massimo di voci presenti in un elenco non relativo a un flusso di lavoro. |
Limiti relativi agli archivi termini (database) dei metadati gestiti
Nella tabella seguente sono riportate le linee guida consigliate per gli archivi termini dei metadati gestiti.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Numero massimo di livelli di termini annidati in un archivio termini |
7 |
Supportato |
I termini di un set di termini possono essere rappresentati gerarchicamente. Un set di termini può avere fino a sette livelli di termini, ovvero un termine padre e sei livelli di nidificazione al di sotto di esso. |
Numero massimo di set di termini in un archivio termini |
1,000 |
Supportato |
In un archivio termini possono essere inclusi fino a 1.000 set di termini. |
Numero massimo di termini in un set di termini |
30,000 |
Supportato |
30.000 è il numero massimo di termini consentiti in un set di termini. Nota Le etichette aggiuntive per uno stesso termine, ad esempio i sinonimi e le traduzioni, non vengono considerate come termini distinti. |
Numero totale di elementi in un archivio termini |
1,000,000 |
Supportato |
Un elemento può essere un termine oppure un set di termini. La somma del numero dei termini e dei set di termini non può superare 1.000.000. Le etichette aggiuntive per uno stesso termine, ad esempio i sinonimi e le traduzioni, non vengono considerate come termini distinti. Nota In un archivio termini non vi possono essere contemporaneamente il numero massimo di set di termini e il numero massimo di termini. |
Numero di etichette di varianti |
209 per archivio termini |
Supportato |
Il numero massimo di etichette di varianti consentito per ogni archivio termini è 209. |
Numero di termini nel set di termini per l'esplorazione gestita |
2,000 |
Supportato |
Il numero massimo supportato di termini in un set di termini Esplorazione gestita è pari a 2.000. |
Numero di termini figli diretti nel set di termini per l'esplorazione gestita |
300 |
Supportato |
Il numero massimo supportato di termini figli diretti in un set di termini Esplorazione gestita è pari a 300. |
Limiti relativi a Visio Services
Nella tabella seguente sono riportate le linee guida consigliate per le istanze di Visio Services in SharePoint Server 2016.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni dei file dei disegni Web di Visio |
50 MB |
Soglia |
In Visio Services è disponibile un'impostazione di configurazione che consente all'amministratore di modificare le dimensioni massime dei disegni Web elaborati da Visio. File di grandi dimensioni possono avere gli effetti seguenti:
|
Timeout di ricalcolo dei disegni Web di Visio |
120 secondi |
Soglia |
In Visio Services è disponibile un'impostazione di configurazione che consente all'amministratore di modificare l'intervallo di tempo massimo consentito per il ricalcolo di un disegno dopo un aggiornamento dei dati. Un timeout di ricalcolo più lungo può avere gli effetti seguenti:
Un timeout di ricalcolo più breve può avere gli effetti seguenti:
|
Validità minima della cache di Visio Services (diagrammi connessi a dati) |
Validità cache minima: da 0 a 24 ore |
Soglia |
La validità minima della cache si applica ai diagrammi connessi a dati. Determina il momento a partire dal quale il diagramma corrente può essere rimosso dalla cache. Se si imposta un valore molto basso come validità minima della cache, diminuirà la velocità effettiva e aumenterà la latenza, in quanto un invalidamento troppo frequente della cache forza Visio a ripetere spesso i calcoli, con una conseguente riduzione della disponibilità della CPU e della memoria. |
Validità massima della cache di Visio Services (diagrammi non connessi a dati) |
Validità cache massima: da 0 a 24 ore |
Soglia |
La validità massima della cache si applica ai diagrammi non connessi a dati. Tale valore determina per quanto tempo il diagramma corrente può restare in memoria. Aumentando la validità massima della cache, diminuisce la latenza per i disegni richiesti comunemente. Se però si imposta un valore molto elevato come validità massima della cache, aumenterà la latenza e diminuirà la velocità effettiva per gli elementi non memorizzati nella cache, in quanto gli elementi già presenti nella cache utilizzano e riducono la memoria disponibile. |
Limiti relativi a PerformancePoint Services
Nella tabella seguente sono riportate le linee guida consigliate per PerformancePoint Services in SharePoint Server 2016.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Celle |
1.000.000 per query sull'origine dati di Excel Services |
Limite |
Una scorecard di PerformancePoint che chiama un'origine dati di Excel Services è soggetta a un limite di 1.000.000 celle per query. |
Colonne e righe |
15 colonne per 60.000 righe |
Soglia |
Numero massimo di colonne e righe durante il rendering di qualsiasi oggetto dashboard di PerformancePoint per cui viene utilizzata una cartella di lavoro di Excel come origine dati. Il numero di righe potrebbe cambiare in base al numero delle colonne. |
Query su un elenco di SharePoint |
15 colonne per 5.000 righe |
Supportato |
Numero massimo di colonne e righe durante il rendering di qualsiasi oggetto dashboard di PerformancePoint per cui viene utilizzato un elenco di SharePoint come origine dati. Il numero di righe potrebbe cambiare in base al numero delle colonne. |
Query su un'origine dati di SQL Server |
15 colonne per 20.000 righe |
Supportato |
Numero massimo di colonne e righe durante il rendering di qualsiasi oggetto dashboard di PerformancePoint per cui viene utilizzato una tabella di SQL Server come origine dati. Il numero di righe potrebbe cambiare in base al numero delle colonne. |
Limiti relativi a Word Automation Services
Nella tabella seguente sono riportate le linee guida consigliate per Word Automation Services.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni dei file di input |
512 MB |
Limite |
Dimensioni massime dei file che possono essere elaborati da Word Automation Services. |
Frequenza con cui avviare le conversioni (minuti) |
1 minuto (consigliato) 15 minuti (predefinito) 59 minuti (limite statico) |
Soglia |
Questa impostazione determina la frequenza di esecuzione del processo timer di Word Automation Services. Specificando un valore più basso, l'esecuzione del processo timer risulta velocizzata. I test eseguiti mostrano che nella maggioranza dei casi è opportuno eseguire tale processo timer una volta al minuto. |
Numero di conversioni da avviare per processo di conversione |
Per i formati di output PDF/XPS: 30 x M Per tutti gli altri formati di output: 72 x M dove M è il valore di frequenza con cui avviare le conversioni (minuti) |
Soglia |
Il numero di conversioni da avviare influisce sulla velocità effettiva di Word Automation Services. Se tali valori vengono impostati su livelli superiori a quelli consigliati, è possibile che alcuni elementi di conversione inizino a presentare problemi a intermittenza e che le autorizzazioni utente scadano. Tali autorizzazioni scadono 24 ore dopo l'avvio di un processo di conversione. |
Dimensioni di un processo di conversione |
100.000 elementi di conversione |
Supportato |
In un processo di conversione sono inclusi uno o più elementi di conversione, ognuno dei quali rappresenta una singola conversione da eseguire su un singolo file di input in SharePoint. Quando un processo di conversione viene avviato utilizzando il metodo ConversionJob.Start, il processo e tutti gli elementi di conversione vengono trasmessi a un server applicazioni che quindi archivia il processo nel database di Word Automation Services. Con un numero elevato di elementi di conversione aumentano anche il tempo di esecuzione del metodo Start e il numero di byte trasmessi al server applicazioni. |
Numero totale di processi di conversione attivi |
N-1, dove N è il numero di core disponibili in ogni server applicazioni |
Soglia |
Un processo di conversione attivo può utilizzare un singolo core di elaborazione. I clienti non dovrebbero pertanto eseguire più processi di conversione di quanti sono i core di elaborazione disponibili nei server applicativi. Il processo timer di conversione e altre attività di SharePoint inoltre richiedono occasionalmente l'utilizzo di un core di elaborazione. È consigliabile lasciare sempre libero un core per l'utilizzo da parte del processo timer di conversione e di SharePoint. |
Dimensioni del database di Word Automation Services |
2 milioni di elementi di conversione |
Supportato |
Word Automation Services mantiene una coda permanente di elementi di conversione nel proprio database. Ogni richiesta di conversione genera uno o più record. Word Automation Services non elimina automaticamente i record dal database, le cui dimensioni possono aumentare in modo incontrollato senza attività di manutenzione. Gli amministratori possono rimuovere manualmente la cronologia dei processi di conversione mediante il cmdlet Remove-SPWordConversionServiceJobHistory di PowerShell. Per altre informazioni, vedere Remove-SPWordConversionServiceJobHistory. |
Limiti relativi al servizio di traduzione automatica
Nella tabella seguente sono riportate le linee guida consigliate per il servizio di traduzione automatica.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni dei file di input per file binari |
524.288 KB per file |
Soglia |
I file che superano questo limite richiedono troppo tempo per essere trasferiti ed elaborati, riducendo la velocità effettiva del servizio. |
Dimensioni dei file di input per file di testo |
15.360 KB per file |
Soglia |
I file che superano questo limite contengono troppo testo da tradurre, riducendo la velocità effettiva del servizio. |
Numero massimo di caratteri per documenti di Microsoft Word |
10.000.000 per documento |
Soglia |
I documenti con un numero di caratteri superiore a questo limite contengono troppo testo da tradurre, riducendo la velocità effettiva del servizio. |
Processi di traduzione simultanei totali |
5 |
Soglia |
Se viene utilizzato un numero di processi superiore a questo limite, la velocità effettiva non aumenta in quanto è previsto un limite relativamente alla quantità di testo che può essere tradotta in una sola volta. Utilizzando più processi, aumentano le richieste per le risorse del server. |
Ritardo tra le traduzioni |
59 minuti |
Soglia |
Se tra l'avvio di una traduzione e quello di un'altra trascorre un intervallo superiore a questo limite, il tempo necessario per tradurre i documenti diventa eccessivo e il numero delle traduzioni in coda può diventare troppo elevato. |
Numero di traduzioni per processo di traduzione |
1.000 per processo |
Soglia |
Se viene avviato un numero di traduzioni superiore a questo limite, le traduzioni avranno esito negativo a causa del verificarsi di un timeout, in quanto non potranno essere elaborate prima della scadenza del periodo previsto. |
Numero massimo di richieste di traduzione simultanee |
300 |
Soglia |
Più di 300 richieste di traduzione simultanee possono causare un timeout delle traduzioni perché le richieste vengono accodate per un periodo di tempo superiore a quello previsto per il timeout. |
File per processo di traduzione |
100.000 file |
Supportato |
Inviando processi con un numero di file superiore a questo limite, il tempo di invio e di elaborazione diventa eccessivo. |
Dimensioni del database del servizio di traduzione automatica |
1.000.000 file |
Supportato |
Le operazioni di manutenzione della coda dei processi si rallentano se il database contiene un numero di file superiore al limite massimo previsto. |
Limiti relativi al servizio Office Online
Nella tabella seguente sono riportate le linee guida consigliate per Office Online. I limiti dell'applicazione client di Office si applicano anche quando un'applicazione viene eseguita come app Web.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni della cache |
100 GB |
Soglia |
Spazio disponibile per il rendering dei documenti creato come parte di un database del contenuto. Per impostazione predefinita, la cache disponibile per il rendering dei documenti è di 100 GB. Non è consigliabile aumentare tale valore. |
Operazioni di rendering |
Una per documento al secondo per core di CPU per server applicazioni (massimo otto core) |
Limite |
Questo è il numero medio misurato delle operazioni di rendering che è possibile eseguire per documenti "tipici" nel server applicazioni in un determinato periodo di tempo. |
Operazioni di unione simultanee di OneNote |
8 per documento |
Soglia |
OneNote unisce le modifiche dei diversi utenti che intervengono in modalità condivisa su un blocco appunti. Se sono già in corso troppe unioni simultanee, verrà generata una pagina di conflitto e l'utente dovrà eseguire manualmente l'unione. |
Limiti relativi a Project Server
Nella tabella seguente sono riportate le linee guida consigliate per Project Server. Per altre informazioni su come effettuare la pianificazione per Project Server, vedere Pianificazione per Project Server 2016.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Data di fine progetto |
Data: 31/12/2149 |
Limite |
I piani di Project non possono estendersi oltre il 31/12/2149. |
Risultati finali per piano di progetto |
1.500 risultati finali |
Limite |
I piani di Project non possono includere più di 1.500 risultati finali. |
Numero di campi in una visualizzazione |
256 |
Limite |
Un utente non può disporre di più di 256 campi in una visualizzazione che hanno definito in Project Web App. |
Numero di clausole in un filtro per una visualizzazione |
50 |
Limite |
Un utente non può aggiungere a una visualizzazione un filtro contenente più di 50 clausole. |
Limiti relativi alle app di SharePoint
Nella tabella seguente sono riportate le linee guida consigliate per le app per SharePoint.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Dimensioni massime dei pacchetti di app di Access/SharePoint |
100 MB |
Statico |
100 MB è il limite per un pacchetto di app creato nel client Access. Nota Access comprime il database quando crea il pacchetto di app in modo che possa includere più di 100 MB di dati. |
Dimensioni massime dell'archiviazione di database delle app di Access in SQL Azure |
1 Gb |
Limite |
Ogni app di Access creata in SharePoint Online crea un database in SQL Azure. 1 GB è il limite per l'archiviazione di database in SQL Azure. In un'installazione locale l'amministratore controlla le dimensioni del database SQL associato. |
App visualizzate nella pagina Gestisci licenze |
2.000 |
Limite |
Nella pagina Gestisci licenze possono essere visualizzate fino a 2.000 app (acquistate da Store). È comunque possibile gestire la licenza di qualsiasi app passando alla pagina Tutto il contenuto del sito specifica del sito in cui è installata l'app e facendo clic su Licenze oppure ricercando l'app mediante Marketplace Search. |
Numero delle licenze di app per tenant |
1.000.000 |
Supportato |
Questo è il numero massimo supportato di licenze (per l'acquisto di app da Store) per una singola distribuzione di SharePoint, che sia locale o SharePoint Online. Se si supera questo limite, le prestazioni possono risentirne in modo significativo. |
Numero di app visualizzate nella pagina Aggiungi un'app |
240 |
Limite |
Dopo che questo limite è stato raggiunto, verranno visualizzate solo le prime 240 app con un messaggio in cui viene spiegato come ricercare l'app desiderata. |
Numero di manager per licenza di app |
30 |
Limite |
Solo 30 persone possono gestire una licenza. I manager delle licenze possono aggiungere o rimuovere utenti, nonché eliminare una licenza. |
Numero di licenze di app assegnate a un utente visualizzabili dall'utente |
2.000 |
Limite |
Quando a un utente sono assegnate più di 2.000 licenze, tale utente non potrà più vedere app nella visualizzazione Aggiungi un'app predefinita. Verrà invece visualizzato un messaggio in cui viene spiegato come effettuare ricerche nel catalogo app o in SharePoint Store. |
Numero di app del catalogo aziendale visualizzabili da un singolo utente |
500 |
Limite |
Quando per un singolo utente sono disponibili più di 500 app del catalogo aziendale, tale utente non potrà più vedere app nella visualizzazione Aggiungi un'app predefinita. Verrà invece visualizzato un messaggio in cui viene spiegato come effettuare ricerche nel catalogo app o in SharePoint Store. |
Limiti relativi al servizio cache distribuita
Nella tabella seguente sono riportate le linee guida consigliate per il servizio cache distribuita.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Numero di entità (utenti, documenti, siti e hashtag) che è possibile seguire per host della cache |
400.000 |
Supportato |
Il numero totale di entità che possono essere seguite da un singolo utente in un host della cache distribuita con 16 GB di RAM assegnati al servizio cache distribuita è pari a 400.000. |
Numero di host della cache in un cluster |
16 |
Limite |
Il numero totale di host della cache che un singolo cluster di cache distribuita può supportare è pari a 16. |
Massima quantità di memoria dedicata a un host della cache |
16 GB |
Limite |
La quantità totale di memoria che può essere dedicata al servizio cache distribuita in qualsiasi host della cache in un cluster è pari a 16 GB. |
Limiti vari
Nella tabella seguente sono riportati i limiti e le linee guida consigliate per servizi e funzionalità non trattati nelle altre sezioni.
| Limite | Valore massimo | Tipo di limite | Note |
|---|---|---|---|
Numero di sottostringhe dell'agente utente per canale dispositivi |
150 |
Limite |
Il numero massimo di sottostringhe dell'agente utente per canale dispositivi mobili è pari a 150. |
Numero di origini di SharePoint per caso di eDiscovery |
100 |
Limite |
Il numero massimo di origini di SharePoint che possono essere aggiunte a un caso di eDiscovery è pari a 100. |
Numero di origini di Exchange (cassette postali) per caso di eDiscovery |
1.500 |
Limite |
Il numero massimo di origini di Exchange (cassette postali) per ogni caso di eDiscovery è pari a 1.500. |
Dimensioni massime di una query di eDescovery |
16.000 caratteri o 500 parole chiave |
Limite |
Una query di eDiscovery può essere costituita al massimo da 500 parole chiave oppure da 16.000 caratteri, a seconda di quale di questi due limiti viene raggiunto per primo. |
Argomenti correlati
Requisiti hardware e software per SharePoint Server 2016
Pianificare le prestazioni di pianificazione in SharePoint Server 2013