Limiti software statici e configurabili per SharePoint Server 2016 e 2019
SI APPLICA A:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Questo articolo descrive i limiti software e i limiti di SharePoint Server 2016 e 2019, tra cui:
Confini: Limiti statici che non possono essere superati dalla 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
[!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.
Informazioni sui limiti di SharePoint in Microsoft 365.
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.
I risultati dei test e le linee guida fornite in questo articolo si applicano a una singola farm di SharePoint Server. L'aggiunta di server all'installazione potrebbe non aumentare i limiti di capacità degli oggetti elencati nelle tabelle nella sezione Limiti e limiti più avanti in questo articolo. 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 possono influire sulle prestazioni in un determinato ambiente e ognuno di questi fattori può influire sulle prestazioni in aree diverse. Alcuni dei risultati dei test e delle raccomandazioni in questo articolo potrebbero essere correlati a funzionalità o operazioni utente che non esistono nell'ambiente e pertanto non si applicano alla soluzione. 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 sono presenti alcuni limiti per progettazione e non possono essere superati e altri limiti impostati su valori predefiniti che possono essere modificati dall'amministratore della farm. Esistono anche alcuni limiti che non sono rappresentati da un valore configurabile, ad esempio il numero di raccolte siti per ogni applicazione Web.
I limiti sono limiti assoluti che non possono essere superati dalla progettazione. È importante comprendere questi limiti per assicurarsi di non fare ipotesi errate quando si progetta la farm.
Un esempio di limite è il limite di dimensioni del documento di 10 gigabyte (GB); Non è possibile configurare SharePoint Server 2016 per archiviare documenti di dimensioni superiori a 10 GB. Questo limite è un valore assoluto predefinito e non può essere superato dalla progettazione.
Le soglie sono un valore predefinito che non può essere superato a meno che il valore non venga modificato. Le soglie possono, in determinate circostanze, essere superate per contenere le variazioni nella progettazione della farm. È importante comprendere che il superamento delle soglie può influire sulle prestazioni della farm oltre al valore effettivo di 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 predefinita per le dimensioni del documento è impostata su 2 gigabyte (GB), ma può essere modificata per 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 impostati per impostazione predefinita sul valore consigliato, mentre altri sono correlati a 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 sapere che molti dei valori limite forniti in questo documento rappresentano un punto di una curva che descrive un aumento del carico delle risorse e una conseguente riduzione delle prestazioni con l'aumento del valore. 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. Tuttavia, nella maggior parte dei casi, operare in corrispondenza o vicino a un limite stabilito non è una procedura consigliata, in quanto gli obiettivi di affidabilità e prestazioni accettabili vengono raggiunti al meglio quando la progettazione di una farm offre un ragionevole equilibrio tra i valori limite.
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 molti limiti in SharePoint Server 2016, ma è importante comprendere in che modo la modifica di un determinato limite influisce su altre parti della farm.
Modalità di definizione dei limiti
In SharePoint Server, le soglie e i limiti supportati vengono stabiliti tramite test e osservazione del comportamento della farm con carichi crescenti fino al punto in cui i servizi e le operazioni della farm raggiungono i limiti operativi effettivi. 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. Pertanto, il valore massimo assegnato al numero di raccolte siti non è assoluto, ma viene calcolato in base a un set previsto di caratteristiche di utilizzo in cui le prestazioni complessive della farm sarebbero accettabili al limite specificato nella maggior parte delle circostanze.
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. È quindi importante eseguire rigorosi esercizi di gestione della capacità e di test di scalabilità per distribuzioni specifiche per stabilire limiti effettivi per tale ambiente.
Nota
Non viene descritto l'hardware usato per convalidare i limiti in questo documento, perché i limiti sono stati raccolti da più farm e ambienti.
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, la cui dimensione rappresenta l'aggregazione di fattori come server, risorse hardware come CPU e RAM, capacità di archiviazione, operazioni di I/O al secondo del disco, larghezza di banda di rete e latenza. La dimensione della torta è quindi correlata alle risorse complessive della farm; l'aggiunta di risorse, ad esempio server farm, aumenta le dimensioni della torta.
Questa torta è suddivisa in sezioni che rappresentano il carico da varie origini: richieste utente, query di ricerca, operazioni su 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 in una farm non è statico (le richieste utente, ad esempio, potrebbero essere significative solo durante determinate ore del giorno), le dimensioni relative delle sezioni sono costantemente in flusso. 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 sui server di database diventa troppo elevato, le lunghezze della coda del disco aumentano, il che a sua volta aumenta 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. Prestazioni accettabili significa che il sistema sottoposto a test può supportare tale numero di oggetti, ma che il numero non può essere superato senza una diminuzione 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 per assicurarsi di non superare le linee guida sulla 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 | Note | Note | 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 | Note | Note | 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: Quantità di memoria allocata ai server Web Carico di lavoro gestito dalla farm, ovvero la base di utenti e le caratteristiche di utilizzo (un singolo pool di applicazioni molto attivo può utilizzare 10 GB e anche oltre) |
Limiti relativi ai database del contenuto
Nella tabella seguente sono riportate le linee guida consigliate per i database del contenuto.
| Limite | Note | Note | 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 ogni applicazione Web, le operazioni degli utenti finali, ad esempio l'apertura del sito o delle raccolte siti, non sono interessate. 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. Con 200 GB per database del contenuto e 500 database del contenuto per farm, SharePoint Server 2016 supporta 100 TB di dati per farm. |
| Dimensioni dei database del contenuto (scenari di utilizzo generali) |
200 GB per database del contenuto |
Supportato |
È 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 usa Archiviazione BLOB remoti, il volume totale di archiviazione BLOB remoti e 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: Prestazioni del sottosistema del disco pari a 0,25 operazioni di I/O al secondo per GB. Sono consigliate 2 operazioni di I/O al secondo per GB per prestazioni ottimali. Sono stati sviluppati piani per disponibilità elevata, ripristino di emergenza, capacità futura e test delle prestazioni. È consigliabile inoltre tenere conto dei fattori seguenti: È possibile che i requisiti per il backup e il ripristino non vengano soddisfatti dal backup di SharePoint Server 2016 nativo per database del contenuto di dimensioni maggiori di 200 GB. È consigliabile valutare e testare le soluzioni di backup e backup alternative di SharePoint Server 2016 per determinare la soluzione migliore per l'ambiente specifico. È consigliabile avere una gestione proattiva degli amministratori esperti delle installazioni di SharePoint Server 2016 e SQL Server. È possibile che la complessità delle personalizzazioni e delle configurazioni di SharePoint Server 2016 richieda il refactoring (o suddivisione) dei dati su più database del contenuto. Consultarsi con un architetto esperto ed eseguire test per determinare le dimensioni ottimali dei database del contenuto per la propria implementazione. Esempi di complessità possono includere distribuzioni di codice personalizzate, uso di più di 20 colonne nella promozione delle proprietà o funzionalità elencate come non da usare nella sezione superiore a 4 TB riportata di seguito. Il refactoring delle raccolte siti consente di implementare la scalabilità orizzontale di una distribuzione di SharePoint Server 2016 su più database del contenuto. In questo modo è possibile implementare una scalabilità illimitata delle distribuzioni di SharePoint Server 2016. Il refactoring potrà essere applicato in modo più semplice e rapido con database del contenuto di dimensioni inferiori a 200 GB. Per semplificare il backup e il ripristino, è consigliabile limitare le singole raccolte siti all'interno di un database del contenuto a 100 GB. Per altre informazioni, vedere Limiti relativi alle raccolte siti. Importante: non è consigliabile usare database del contenuto che superano i 4 Terabyte (TB), ad eccezione degli scenari di archivio documenti (descritti nella riga successiva di questa tabella). If, in the future, you need to upgrade your SharePoint Server 2016 installation, upgrading the site collections within the content databases can be very difficult and time consuming. > È consigliabile aumentare il numero di istanze tra più database del contenuto anziché superare i 4 TB di dati in un singolo database del contenuto. |
| 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: Devono essere soddisfatti tutti i requisiti definiti nella sezione "Dimensioni dei database del contenuto (tutti gli scenari di utilizzo)" più indietro in questa tabella e devono essere stati considerati attentamente tutti i fattori illustrati nella relativa sezione Note. I siti di SharePoint Server 2016 devono basarsi su modelli di sito del Centro documenti o del Centro record. Ogni mese deve essere aperto in media meno del 5% del contenuto del database del contenuto e deve esserne modificato o scritto in media meno dell'1%. Non usare avvisi, flussi di lavoro, correzioni di collegamento o sicurezza a livello di elemento in oggetti di SharePoint Server 2016 nel database del contenuto. > [! NOTA] I> database del contenuto dell'archivio documenti possono essere configurati per accettare documenti dai flussi di lavoro di routing del contenuto. |
| 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. In un database del contenuto con un massimo di 10.000 raccolte siti totali, un massimo di 2.500 di queste possono essere raccolte siti non personali. È possibile supportare 10.000 raccolte siti personali se sono le uniche raccolte siti all'interno del 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.
| Valore massimo | Note | Note | 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. Questo limite è influenzato da altri fattori che potrebbero ridurre il numero effettivo di raccolte siti che possono essere supportate da un determinato database del contenuto. 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. Tuttavia, se ogni database del contenuto contiene 10.000 raccolte siti, anche se questo numero è supportato per un database del contenuto, il numero totale di raccolte siti nella farm è 2.000.000, che supera il limite per il numero di raccolte siti per applicazione Web. L'utilizzo della memoria nei server Web deve essere monitorato, poiché l'utilizzo della memoria dipende dai modelli di utilizzo e dal numero di siti a cui si accede in un determinato intervallo di tempo. Analogamente, le destinazioni di ricerca per indicizzazione potrebbero anche presentare un carico di memoria elevato e, in tal caso, il pool di applicazioni deve essere configurato per il riciclo prima che la memoria disponibile in qualsiasi server Web venga ridotta a meno di 2 GB. |
| Sito Web |
250.000 per raccolta siti / 250.000 per farm / 500.000 siti personali per farm. |
Supportato |
Anche se il limite supportato per il numero di siti Web in una raccolta siti è 250.000, il limite consigliato è 2.000. Le prestazioni possono diminuire quando il numero di siti Web supera 2.000 in una raccolta siti. Importante: è consigliabile rimanere al di sotto di 2.000 siti Web per raccolta siti. È possibile creare un numero totale molto elevato di siti Web creando più raccolte siti con un massimo di 2000 siti Web per ogni raccolta siti. Ad esempio, 125 raccolte siti che contengono 2.000 siti Web ciascuna equivarranno a 250.000 siti Web nella farm. Questo sarebbe considerato il limite massimo consigliato per i siti non personali. Se sono presenti 250.000 raccolte siti, tutte contenenti un sito Web radice che non è il modello sito personale, l'aggiunta di un sito Web secondario a uno di questi siti Web radice supererebbe il limite di 250.000 siti Web. Se viene superato il limite consigliato di 2.000 siti Web per ogni raccolta siti, potrebbero verificarsi i problemi seguenti: L'eliminazione o la creazione di un sito Web può influire sulla disponibilità di altri siti Web della stessa raccolta siti. L’accesso ai siti Web nella raccolta siti verrà limitato mentre il sito Web viene eliminato. Potrebbe inoltre non riuscire il tentativo di creare numerosi siti Web nello stesso momento. Quando si dispone di più di 2.000 siti Web, si riducono drasticamente le prestazioni per operazioni quali l'esecuzione di PSConfig quando si aggiunge un nuovo server a una farm esistente o dopo l'installazione di aggiornamenti di SharePoint. L'esecuzione di operazioni di stsadm -o checklocalupgradestatus oppure l'esecuzione giornaliera del processo timer del processo della versione prodotto potrebbe richiedere molte ore. L'esplorazione della pagina Rivedi stato database (<your_SharePoint_CentralAdmin_URL>/_admin/UpgradeStatus.aspx) nel sito Web Amministrazione centrale può causare un timeout. |
| 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: Alcune azioni relative alle raccolte siti, ad esempio il backup o ripristino oppure l'esecuzione del cmdlet Move-SPSite di PowerShell, danno luogo a complesse operazioni di SQL Server che possono incidere sulle prestazioni o avere esito negativo se nello stesso database sono attive altre raccolte siti. Per altre informazioni, vedere Move-SPSite. Il backup e il ripristino della raccolta siti di SharePoint sono supportati solo per una dimensione massima della raccolta siti di 100 GB. Per raccolte siti di dimensioni maggiori, è necessario eseguire il backup dell'intero database del contenuto. Se in un singolo database del contenuto sono incluse più raccolte siti di dimensioni maggiori di 100 GB, è possibile che le operazioni di backup e ripristino richiedano molto tempo e abbiano esito negativo. |
| 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 | Note | Note | 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 |
Le dimensioni predefinite del file sono di 2 gigabyte (GB) (2.047 MB). Tuttavia, un volume elevato di file di grandi dimensioni può influire sulle prestazioni della farm. NOTE: in SharePoint Server 2019 il limite file è di 15 GB. |
| 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. Questo non si applica alle operazioni a singolo elemento. 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 raccolta che un'operazione di database, ad esempio una query, può elaborare contemporaneamente quando vengono eseguiti da un revisore o da un amministratore con le autorizzazioni appropriate. Questa impostazione è correlata a Ignora modello a oggetti. |
| Siti secondari |
2.000 per visualizzazione sito |
Soglia |
L'interfaccia per l'enumerazione dei siti secondari di un determinato sito Web non funziona correttamente, mentre il numero di siti secondari supera i 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 |
Il numero massimo di ambiti di sicurezza univoci impostati per un elenco non può superare i 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 è il limite di sicurezza per un oggetto a protezione diretta e uno dei relativi elementi figlio che non hanno un limite di sicurezza separato definito. 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 i 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. Ogni volta che il numero massimo di oggetti figlio con ambiti univoci è maggiore di 500 propagazione ACL non deve essere usato. |
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 in un elenco di SharePoint non può superare gli 8.000 byte.
| Limite | Numero massimo colonne per query | 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 (selezioni multiple) |
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 |
SQL Server ritorno a capo delle righe si verifica dopo ogni otto colonne in 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). |
| Numero 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: Un campo di ricerca per il tag effettivo Un campo di testo nascosto per il valore stringa Un campo di ricerca per gli elementi pertinenti Un campo di ricerca per gli elementi non pertinenti (spill-over) Per ogni campo Metadati gestiti successivo aggiunto a un elenco vengono aggiunte altre due colonne: Un campo di ricerca per il tag effettivo Un campo di testo nascosto per il valore stringa Il numero massimo di colonne di metadati gestiti viene calcolato come (14 + (16 * (n-1))) dove n è il valore di mapping delle righe (impostazione predefinita 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, dato un tipo di contenuto esterno "Customer", che include campi come "ID", "Name", "Country" e "Description", quando si aggiunge una colonna Dati esterni di tipo "Customer" 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 nascosto: campo di testo a 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.
| Tipo di limite | Note | Note | 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
| Valore massimo | Note | Note | 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: Le dimensioni del token utente La cache dei gruppi: in SharePoint Server 2016 è disponibile una tabella che memorizza nella cache il numero di gruppi a cui appartiene un utente non appena tali gruppi vengono utilizzati in elenchi di controllo di accesso. Il tempo necessario per il controllo di sicurezza: man mano che aumenta il numero dei gruppi a cui appartiene un utente, aumenta anche il tempo necessario per il controllo di accesso. |
| 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: Recupero degli utenti per la convalida delle autorizzazioni. Questa operazione richiede in modo incrementale sempre più tempo man mano che aumenta il numero degli utenti di un gruppo. Rendering dell'appartenenza della visualizzazione. Questa operazione richiederà sempre tempo. |
| Gruppi di SharePoint |
10.000 per raccolta siti |
Supportato |
Oltre 10.000 gruppi, il tempo necessario per eseguire le operazioni è aumentato in modo significativo. Ciò vale soprattutto per l'aggiunta di un utente a un gruppo esistente, la creazione di un nuovo gruppo e il rendering delle visualizzazioni di 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 esiste un limite rigido, ma più grande è l'ambito, più tempo richiede 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 | Note | Note | 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. Quando si esegue il ridimensionamento, aggiungere un database di report di analisi quando le dimensioni di uno dei database di analisi distribuiti raggiungono le dimensioni totali di 250 GB o 20 M di righe totali. 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 di core fisici nell'host è uguale a N, il componente di elaborazione del contenuto ha NK sessioni di alimentazione. K è un coefficiente costante con il valore iniziale 3. Un server a 4 core ha 12 sessioni di alimentazione, il che significa che il componente di elaborazione del contenuto può 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 verso l'alto a 12, anche se un server ha più di 12 core fisici. Pertanto, un server a 16 core ha NK = 12 * 3 = 36 sessioni di alimentazione. 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 contenuto è associato un sovraccarico, pertanto è consigliabile creare il numero minimo di origini di contenuto che soddisfano gli altri requisiti operativi, ad esempio le differenze nella priorità e nella pianificazione della ricerca per 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 viene visualizzato un avviso che indica che il file ha superato le dimensioni massime scaricabili dal crawler.
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 (4 MB per i documenti di Excel) |
Soglia |
La ricerca scarica i metadati e il contenuto da un documento fino a raggiungere le dimensioni massime del documento. Il resto del contenuto non viene scaricato. La ricerca scarica sempre i metadati di un documento. È 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. Il numero effettivo di caratteri analizzati può essere inferiore a questo limite perché la ricerca usa al massimo 30 secondi per l'analisi di un singolo elemento e dei 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. Il numero effettivo di elementi elaborati può essere inferiore a questo limite perché la ricerca usa al massimo 30 secondi per l'interruzione di parola. 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 |
Questo tipo di limite è il valore predefinito per le dimensioni massime di una proprietà gestita impostata su "ricercabile" o "queryable". È 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 questo limite, si abilita l'indicizzazione di più dati per ogni 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 tipo di limite è il valore predefinito per le dimensioni massime di una proprietà gestita recuperabile. Se si aumenta questo limite, si abilita l'indicizzazione di più dati per ogni 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. L'indicizzazione e il recupero di un numero maggiore di dati per proprietà gestita aumenta il carico generale del sistema di ricerca e utilizza più spazio del disco. È 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 questo limite, si abilita l'indicizzazione di più dati per ogni 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 |
Questo tipo di limite è la dimensione massima di una proprietà gestita ordinabile e per affinamento ricerca. |
| Dimensioni dei token |
Variabile |
Limite |
La ricerca può indicizzare i token di qualsiasi lunghezza. Ma il word breaker usato dalla ricerca per produrre token può limitare la lunghezza del token. Word i breaker sono componenti in grado di riconoscere la lingua che interrompono il contenuto in singole parole (token). È anche possibile creare word breaker personalizzati. Il limite di dimensioni del token dipende quindi dal word breaker. Di seguito è riportato il limite del word breaker per le lingue occidentali: Il word breaker considera solo i primi 1000 caratteri di un token ai fini della suddivisione e ignora tutti i caratteri restanti. Il word breaker suddivide i token con una lunghezza superiore a 300 caratteri in due o più token di un massimo di 300 caratteri ognuno. Ad esempio, un token di 612 caratteri viene suddiviso in due token di 300 caratteri e in un token di 12 caratteri. |
| Token indicizzati univoci per proprietà gestita |
1.000.000 |
Soglia |
Questo tipo di limite è il numero massimo di token univoci che possono essere aggiunti all'indice di ricerca per ogni proprietà gestita. Questo limite non può essere modificato. Se il limite viene superato, l'indice contiene i primi 1.000.000 token della proprietà gestita e il file verrà contrassegnato come parzialmente elaborato impostando la proprietà IsPartiallyProcessed su true. Eccezione: se viene raggiunto il limite per una proprietà gestita relativa ad ACL, all'indice non vengono aggiunti token da tale proprietà gestita. |
| Utenti distinti o gruppi di sicurezza di Active Directory con accesso a un elemento |
1.000.000 |
Soglia |
Quando più di 1 milione di utenti distinti o gruppi di sicurezza di Active Directory hanno accesso a un elemento, l'elemento non è disponibile per la ricerca da parte di alcun utente. Questi elementi vengono restituiti solo come parte di una query di eDiscovery tramite il Centro sicurezza & conformità. |
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.
| Tipo di limite | Note | Note | 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 tipo di limite limita il numero di termini consentiti per i dizionari inclusioni ed esclusioni per la correzione ortografica delle query e l'estrazione aziendale. È 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.
| Tipo di limite | Note | Note | 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 di proprietà sottoposte a ricerca per indicizzazione supera questo limite supportato, la velocità di indicizzazione viene ridotta. |
| 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 tipo di limite è il numero massimo di valori per ogni proprietà gestita multivalore gestita per 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 tipo di limite è il numero massimo di proprietà di metadati che il componente di ricerca per indicizzazione può determinare durante la ricerca per indicizzazione di 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
| Tipo di limite | Note | Note | 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 per le query e i risultati proteggono il motore di ricerca dall'esecuzione di espressioni di query di grandi dimensioni e dalla restituzione di set di risultati di grandi dimensioni. Impedire al motore di ricerca di eseguire espressioni di query di grandi dimensioni e restituire set di risultati di grandi dimensioni impedisce gli attacchi Denial of Service (DoS) e garantisce che i risultati vengano restituiti tempestivamente. Se è necessario recuperare altri risultati, è consigliabile usare il paging.
| Valore massimo | Note | Note | Note |
|---|---|---|---|
| Lunghezza del testo per le query che utilizzano il linguaggio Keyword Query Language |
4 KB (4.096 caratteri) |
Supportato |
Questo tipo di limite è il valore predefinito e testato per la lunghezza massima del testo per una query compilata usando il linguaggio di query con parole chiave, ad eccezione delle query di individuazione. Per tali query, il valore massimo predefinito è 16 KB (16.384 caratteri). 500 righe |
| Lunghezza di testo per le query sulla pagina iniziale di SharePoint |
16 KB (16.384 caratteri) |
Supportato |
Questo limite si applica solo all'anteprima pubblica di SharePoint Server 2019. Questo tipo di limite è il valore predefinito e testato per la lunghezza massima del testo per una query usata nella home page di SharePoint. Il valore predefinito per la lunghezza massima del testo può essere aumentato fino al limite di 20 KB (20.480). |
| Supportato |
500 righe |
Supportato |
Questo tipo di limite è il valore predefinito e testato per il numero massimo di righe in un set di risultati, ad eccezione di una 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 notifica all'utente finale. Questo tipo di limite è il limite testato per un'applicazione servizio di ricerca con una combinazione di query dell'utente finale (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.
| Tipo di limite | Note | Note | 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 tipo di limite indica il numero massimo di contesti univoci per ogni modello di classificazione. |
| Pagine rilevanti |
Una 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.
| Tipo di limite | Note | Note | 2^31 (2 miliardi di termini) |
|---|---|---|---|
| Termini univoci nell'indice |
2^31 (>2 miliardi di termini) |
Limite |
Questo tipo di limite è 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 tipo di limite è 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 di elementi indicizzati è elevato in relazione alla quantità di memoria del server, questa sproduzione influisce negativamente sul tempo di risposta della query. |
Limiti relativi al servizio profili utente
Nella tabella seguente sono riportate le linee guida consigliate per il servizio profili utente.
| Tipo di limite | Note | Note | 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 sono supportati fino a 500 milioni di tag di social networking, note e valutazioni totali senza una riduzione significativa delle 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.
| Tipo di limite | Note | Note | Note |
|---|---|---|---|
| Processi di distribuzione del contenuto in esecuzione in percorsi diversi |
20 |
Supportato |
Per l'esecuzione simultanea di processi in percorsi connessi alle raccolte siti nello stesso database del contenuto di origine, esiste un rischio maggiore di deadlock nel database. Per i processi che devono essere eseguiti tutti contemporaneamente, è consigliabile spostare le raccolte siti in database del contenuto di origine diversi. Nota: i processi in esecuzione simultanei nello stesso percorso non sono possibili. Se si usano snapshot SQL Server per la distribuzione del contenuto, ogni percorso crea uno snapshot. Questa correlazione snapshot-path aumenta i requisiti di I/O 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.
| Tipo di limite | Note | Note | 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.
| Tipo di limite | Note | Note | 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 di sistema esterne attive/aperte in un determinato momento. Il valore massimo predefinito è 200; il limite è 500. Questo limite viene applicato nell'ambito del server Web, indipendentemente dal tipo di sistema esterno (ad esempio, database, assembly .NET e così via) Il valore massimo predefinito viene usato per limitare il numero di connessioni. Un'applicazione può specificare un limite maggiore tramite il contesto di esecuzione; il limite impone il 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 connettore di database usa un massimo predefinito di 2.000 per limitare il numero di risultati che possono essere restituiti per pagina. L'applicazione può specificare un limite maggiore tramite il contesto di esecuzione; Il valore Massimo assoluto applica il 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 maggiore tramite il contesto di esecuzione; il valore max assoluto impone il massimo consentito anche per le applicazioni che non rispettano il valore predefinito, ad esempio l'indicizzazione. |
Limiti relativi ai flussi di lavoro
Nella tabella seguente sono riportate le linee guida consigliate per il flusso di lavoro.
| Tipo di limite | Note | Note | 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 questa soglia, le nuove richieste di attivazione dei flussi di lavoro vengono accodate per essere eseguite dal servizio timer del flusso di lavoro in un secondo momento. Quando l'esecuzione non timer viene completata, le nuove richieste vengono conteggiate rispetto a questa soglia. Questo limite può essere configurato usando il cmdlet di PowerShell Set-SPFarmConfig. Per altre informazioni, vedere Set-SPFarmConfig. Nota: questo limite non fa riferimento al numero totale di istanze del flusso di lavoro che possono essere in corso. 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. È configurabile usando PowerShell. Per consentire altri eventi, è possibile eseguire più istanze del servizio Timer del flusso di lavoro di SharePoint Foundation. |
| Associazioni di flusso di lavoro |
100 per elenco |
Supportato |
Il superamento di questo limite peggiora le prestazioni del browser a causa dell'elevato volume di dati caricati 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 il limite di dimensioni non riescono. |
| Profondità massima di un passaggio secondario dei flussi di lavoro in XAML (complessità dei flussi di lavoro) |
121 livelli |
Limite |
Esiste un limite massimo di 125 per la profondità del nodo 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 |
Statico |
I test hanno confermato che un server Web SharePoint può attivare un massimo di sei istanze del flusso di lavoro al secondo. Questo numero è cumulativo, pertanto varia in base al numero di server Web presenti nella farm. Ad esempio, due server Web possono attivare 12 istanze del flusso di lavoro al secondo e tre server Web possono attivarsi 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 livello di volume verrà superato, è consigliabile aggiungere un server Web con carico aggiuntivo alla farm di SharePoint. 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 usati per questo test erano macchine virtuali Hyper-V con 16 core processor e 24 GB di RAM ciascuno. |
| 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 del 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 questo limite viene superato, le ricerche del flusso di lavoro nei campi non indicizzati hanno esito negativo per gli utenti non amministratori. 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 |
Il test ha confermato che le prestazioni delle associazioni del flusso di lavoro di avvio automatico non sono interessate quando le dimensioni dell'elenco aumentano a 1 milione di elementi. Because response time doesn't change as list size scales, the effective limit is the same as the maximum number of items in a non-workflow list. |
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.
| Tipo di limite | Note | Note | 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 lo stesso termine, ad esempio sinonimi e traduzioni, non vengono conteggiate come termini separati. |
| 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 di termini e set di termini non può superare 1.000.000. Le etichette aggiuntive per lo stesso termine, ad esempio sinonimi e traduzioni, non vengono conteggiate come termini separati. Nota: non è possibile avere sia il numero massimo di set di termini che il numero massimo di termini contemporaneamente in un archivio 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 | Note | Note | Note |
|---|---|---|---|
| Soglia |
50 MB |
Soglia |
Aumento del footprint di memoria di Visio Services. File di grandi dimensioni possono avere gli effetti seguenti: Riduzione delle richieste per il server applicazioni al secondo. Aumento dell'utilizzo della CPU. Riduzione delle richieste per il server applicazioni al secondo. Aumento della latenza complessiva. Aumento del carico di rete per la farm di SharePoint. |
| Soglia |
120 secondi |
Soglia |
Riduzione della disponibilità della CPU e della memoria. Un timeout di ricalcolo più lungo può avere gli effetti seguenti: Riduzione della disponibilità della CPU e della memoria. Riduzione delle richieste per le applicazioni al secondo. Aumento della latenza media tra tutti i documenti. Un timeout di ricalcolo più breve può avere gli effetti seguenti: Riduzione della complessità dei diagrammi che è possibile visualizzare. Aumento delle richieste al secondo. Riduzione della latenza media tra tutti i documenti. |
| Soglia |
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. L'impostazione dell'età minima della cache su un valore basso riduce la velocità effettiva e aumenta la latenza, perché la convalida della cache troppo spesso impone a Visio di ricalcolare spesso e riduce la disponibilità di CPU e memoria. |
| Soglia |
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. Tuttavia, l'impostazione di Età massima cache su un valore elevato aumenta la latenza e rallenta la velocità effettiva per gli elementi non memorizzati nella cache, perché 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 | Note | Note | Note |
|---|---|---|---|
| Celle |
Una scorecard di PerformancePoint che chiama un'origine dati di Excel Services è soggetta a un limite di 1.000.000 celle per query. |
Limite |
15 colonne per 60.000 righe |
| 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 che usa 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.
| Tipo di limite | Note | Note | 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) Soglia 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 mostrano che è più utile eseguire questo processo timer una volta al minuto. |
| Numero di conversioni da avviare per processo di conversione |
Il numero di conversioni da avviare influisce sulla velocità effettiva di Word Automation Services. |
Soglia |
Il numero di conversioni da avviare influisce sulla velocità effettiva di Word Automation Services. Se questi valori sono impostati su livelli superiori a quelli consigliati, alcuni elementi di conversione potrebbero iniziare a non riuscire in modo intermittente e le autorizzazioni utente potrebbero scadere. 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 viene avviato un processo di conversione (tramite il metodo ConversionJob.Start), il processo di conversione e tutti gli elementi di conversione vengono trasmessi a un server applicazioni che archivia il processo nel database Word Automation Services. Un numero elevato di elementi di conversione aumenta sia il tempo di esecuzione del metodo Start che 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. Di conseguenza, i clienti non devono eseguire più processi di conversione rispetto ai core di elaborazione nei server applicazioni. 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, quindi il database può crescere a tempo indeterminato senza 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.
| Tipo di limite | Note | Note | 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 |
L'uso di più processi rispetto al limite non aumenta la velocità effettiva perché esiste un limite alla quantità di testo che è possibile tradurre alla 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 |
L'avvio di più traduzioni rispetto al limite causa l'esito negativo delle traduzioni a causa del timeout perché non possono essere elaborate prima del periodo di timeout. |
| 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 | Note | Note | 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 la cache disponibile. |
| Operazioni di rendering |
Una per documento al secondo per core di CPU per server applicazioni (massimo otto core) |
Limite |
Si tratta del numero medio misurato delle operazioni di rendering che è possibile eseguire per documenti "tipici" nel server applicazioni in un determinato periodo di tempo. |
| Soglia |
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 Planning and architecture for Project Server 2010.
| Limite | Note | Note | Note |
|---|---|---|---|
| Data di fine progetto |
Data: 31/12/2149 |
Limite |
I piani di progetto non possono estendersi oltre la data 31/12/2149. |
| Risultati finali per piano di progetto |
1.500 risultati finali |
Limite |
I piani di progetto non possono contenere più di 1.500 risultati finali. |
| Numero di campi in una visualizzazione |
256 |
Limite |
Un utente non può aggiungere più di 256 campi a una visualizzazione definita in Project Web App. |
| Numero di clausole in un filtro per una visualizzazione |
50 |
Limite |
Un utente non può aggiungere un filtro a una visualizzazione che contiene più di 50 clausole. |
Limiti relativi alle app di SharePoint
Nella tabella seguente sono riportate le linee guida consigliate per le app per SharePoint.
| Tipo di limite | Note | Note | Note |
|---|---|---|---|
| Dimensioni massime dei pacchetti di app di Access/SharePoint |
100 MB |
Statico |
Dimensioni massime dell'archiviazione di database delle app di Access in SQL Azure > [! NOTA]> Access comprime il database quando crea il pacchetto dell'app, quindi il pacchetto dell'app può 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 Access creata in SharePoint 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 |
Numero massimo supportato di licenze (acquisto di app dallo Store) per una singola distribuzione di SharePoint, locale o SharePoint in Microsoft 365. 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 vengono assegnate più di 2.000 licenze a un utente, l'utente non visualizzerà più alcuna app nella visualizzazione Aggiungi 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 più di 500 app del catalogo aziendale sono disponibili per un singolo utente, l'utente non visualizzerà più alcuna app nella visualizzazione Aggiungi 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.
| Tipo di limite | Note | Note | 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 cache distribuita con 16 GB di RAM assegnati al servizio cache distribuita è 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.
| Tipo di limite | Note | Note | 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. |
Articoli correlati
Requisiti hardware e software per SharePoint Server 2016
Pianificare le prestazioni di pianificazione in SharePoint Server 2013
Gestione della capacità di SharePoint Server 2010: limiti del software