Limiti software statici e configurabili per SharePoint 2013
SI APPLICA A:
2013 
2016 2019 Subscription Edition SharePoint in Microsoft 365
Questo articolo descrive i limiti software e i limiti di SharePoint Server 2013, 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.
Importante
[!IMPORTANTE] Alcuni valori riportati in questo articolo si basano sui risultati dei test dei Prodotti SharePoint 2010 e potrebbero non rappresentare i valori finali per SharePoint Server 2013. L'articolo verrà aggiornato con i valori appropriati quando saranno disponibili i dati dei test relativi a SharePoint Server 2013. > Per informazioni sui requisiti hardware e software correnti, vedere Requisiti hardware e software per SharePoint 2013.
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 2013 e vengono indicate linee guida per ottenere prestazioni accettabili a fronte dei limiti previsti. Le informazioni contenute in questo articolo consentono di stabilire se il livello di prestazioni e i limiti di capacità della distribuzione pianificata sono accettabili e di configurare in modo appropriato limiti per l'ambiente in uso.
Le linee guida e i risultati dei test forniti in questo articolo si applicano a una singola farm di SharePoint Server 2013. 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 2013 esistono alcuni limiti che sono in base alla progettazione e non possono essere superati. Alcuni altri limiti sono impostati sui 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 2 GB; Non è possibile configurare SharePoint Server 2013 per archiviare documenti di dimensioni superiori a 2 GB. Questo limite è un valore assoluto predefinito e non può essere superato dalla progettazione.
Una soglia è un parametro con 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. Tuttavia, è importante comprendere che il superamento della soglia potrebbe 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 250 MB, ma può essere modificata per supportare il limite massimo di 2 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. Molti limiti in SharePoint Server 2013 possono essere modificati, 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 2013 le soglie e i limiti supportati vengono stabiliti mediante l'esecuzione di test e l'osservazione del comportamento della farm, la quale viene sottoposta a carichi crescenti fino al raggiungimento dei limiti operativi effettivi da parte dei servizi e delle attività della farm. Alcuni servizi e componenti della farm possono gestire un carico superiore a quello di altri elementi, pertanto in alcuni casi è necessario assegnare un valore limite basato su una media di diversi fattori.
Le osservazioni relative al comportamento della farm sotto carico quando vengono aggiunte raccolte siti indicano ad esempio che alcune funzionalità presentano livelli di latenza eccessivamente elevati mentre altre funzionalità continuano a operare entro parametri accettabili. 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 operano con parametri superiori a quelli usati per il test dei limiti, i limiti massimi effettivi di altri servizi verranno ridotti. È 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 risorse hardware, carico e prestazioni, è importante avere un modo per visualizzare i fattori coinvolti e il modo in cui si influiscono l'uno sull'altro.
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 diverse origini: richieste utente, query di ricerca, operazioni sulle funzionalità installate, processi timer e sovraccarico del sistema operativo. Ciascuna di queste sezioni deve condividere le risorse disponibili della farm. Se le dimensioni di una di tali sezioni aumentano, devono diminuire proporzionalmente le dimensioni delle altre sezioni. Poiché il carico 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 2013.
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. Creare altre raccolte siti denominate host dove possibile 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 le prestazioni di sistema 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. È possibile configurare le dimensioni della cache delle soluzioni utilizzando il cmdlet Set-SPInfoPathFormsService di PowerShell. Per altre informazioni, vedere Set-SPInfoPathFormsService. |
Limiti relativi ai server Web e ai server applicazioni
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 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 2013 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, tranne quando si applicano le circostanze 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: Le prestazioni del sottosistema del disco di 0,25 operazioni di I/O al secondo per GB, due operazioni di I/O al secondo per GB sono consigliate per prestazioni ottimali. Sono stati sviluppati piani per disponibilità elevata, ripristino di emergenza, capacità futura e test delle prestazioni. Considerare i fattori seguenti: È possibile che i requisiti per il backup e il ripristino non vengano soddisfatti dal backup di SharePoint Server 2013 nativo per database del contenuto di dimensioni maggiori di 200 GB. Valutare e testare le soluzioni di backup e backup alternative di SharePoint Server 2013 per determinare la soluzione migliore per l'ambiente specifico. È consigliabile avere una gestione proattiva degli amministratori esperti delle installazioni di SharePoint Server 2013 e SQL Server. È possibile che la complessità delle personalizzazioni e delle configurazioni di SharePoint Server 2013 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 nell'innalzamento di livello 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 2013 su più database del contenuto. Questo provisioning consente alle implementazioni di SharePoint Server 2013 di essere ridimensionate a tempo indeterminato. 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 TB, ad eccezione degli scenari di archivio documenti (descritti nella riga successiva di questa tabella). Se in futuro sarà necessario aggiornare l'installazione di SharePoint Server 2013, l'aggiornamento delle raccolte siti all'interno dei database del contenuto può essere difficile e richiede molto tempo. > È 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: Soddisfare tutti i requisiti del limite "Dimensioni del database del contenuto (tutti gli scenari di utilizzo)" più indietro in questa tabella ed è necessario assicurarsi di aver considerato attentamente tutti i fattori descritti nel campo Note di tale limite. I siti di SharePoint Server 2013 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 collegamenti o sicurezza a livello di elemento in oggetti di SharePoint Server 2013 nel database del contenuto. Note: Document archive content databases can be configured to accept documents from Content Routing workflows. For more information about large-scale document repositories, see Estimate performance and capacity requirements for large scale document repositories in SharePoint Server 2010, and the Typical large-scale content management scenarios section of the article Enterprise content storage planning (SharePoint Server 2010). |
| 60 milioni di elementi, inclusi documenti ed elementi di elenco |
60 milioni di elementi, inclusi documenti ed elementi di elenco |
Il numero massimo di elementi per database del contenuto che è stato sottoposto a test in SharePoint Server 2013 è 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 2013, è necessario distribuire più database del contenuto. |
Il numero massimo di elementi per database del contenuto testati in SharePoint Server 2013 è di 60 milioni di elementi, inclusi documenti ed elementi di elenco. Se si prevede di archiviare più di 60 milioni di elementi in SharePoint Server 2013, è necessario distribuire più database del contenuto. |
| 10.000 al massimo (2.500 raccolte siti non personali e 7.500 siti personali oppure soltanto 10.000 siti personali) |
10.000 al massimo (2.500 raccolte siti non personali e 7.500 siti personali oppure soltanto 10.000 siti personali) |
Supportato |
È consigliabile limitare il numero di raccolte siti in un database del contenuto a 5.000. È 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 raccolte può 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 avere una strategia di aggiornamento chiara per affrontare la lunghezza dell'interruzione e l'impatto sulle operazioni e ottenere hardware aggiuntivo per velocizzare gli aggiornamenti software che influiscono sui database. To set the warning and maximum levels for the number of sites in a content database, use the PowerShell cmdlet Set-SPContentDatabase with the -WarningSiteCount parameter. Per altre informazioni, vedere [Set-SPContentDatabase]/powershell/module/sharepoint-server/Set-SPContentDatabase?view=sharepoint-ps&preserve-view=true). |
| 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. |
Quando SharePoint Server 2013 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 2013 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 |
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 |
Supportato |
Supportato |
Il numero massimo consigliato di siti per farm è 500.000 raccolte siti contenenti un solo sito personale più 250.000 raccolte siti contenenti altre raccolte siti per tutti gli altri modelli di sito. 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. In tal caso, è opportuno configurare il pool di applicazioni per il riciclaggio prima che la quantità di memoria disponibile in qualsiasi server Web scenda al di sotto di 2 GB. 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. |
Il numero massimo di siti Web consigliato è 500.000 siti basati sul modello del sito personale e 250.000 basati su tutti gli altri modelli. Il limite si applica a ogni raccolta siti e a ogni farm. |
Il numero massimo di siti Web consigliato è 500.000 siti basati sul modello del sito personale e 250.000 basati su tutti gli altri modelli. Questo limite si applica per raccolta siti e per farm. Le prestazioni possono diminuire quando il numero di siti secondari supera 2.000 a livello di raccolta siti. IMPORTANTE: è consigliabile rimanere al di sotto di 2.000 siti secondari per ogni raccolta siti. È possibile creare un numero totale elevato di siti Web creando più raccolte siti con un massimo di 2.000 siti Web per ogni raccolta siti. Ad esempio, 125 raccolte siti che contengono 2.000 web equivalgono a 250.000 siti nella farm. Tuttavia, questa soglia sarebbe considerata 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 secondario a uno di questi siti radice supererebbe il limite di 250.000 siti Web. Se viene superato il limite consigliato di 2.000 siti per ogni raccolta siti, potrebbero verificarsi i problemi seguenti: L'eliminazione o la creazione di un sito o di un sito secondario può influire in modo significativo sulla disponibilità di un sito. L’accesso ai siti e ai siti secondari verrà limitato mentre il sito viene eliminato. Potrebbe inoltre non riuscire il tentativo di creare numerosi siti secondari nello stesso momento. Quando si hanno più di 2.000 siti secondari, le prestazioni di azioni come l'esecuzione di PSConfig quando si aggiunge un nuovo server a una farm esistente o dopo l'installazione degli aggiornamenti di SharePoint possono diminuire drasticamente. 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. In generale, è consigliabile limitare le dimensioni delle raccolte siti a 100 GB per i motivi seguenti: Alcune azioni della raccolta siti, ad esempio il backup/ripristino della raccolta siti o il cmdlet di PowerShell Move-SPSite, causano operazioni di SQL Server di grandi dimensioni che possono influire sulle prestazioni o avere esito negativo se altre raccolte siti sono attive nello stesso database. Per altre informazioni, vedere Move-SPSite. Le operazioni di backup e ripristino delle raccolte siti di SharePoint sono supportate solo per una dimensione massima di raccolte siti pari a 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 |
2 GB |
Le dimensioni massime predefinite per i file sono pari a 250 MB. Tale limite è configurabile e può essere portato a 2 GB (2.047 MB), ma un numero elevato di file di dimensioni particolarmente grandi può incidere negativamente sulle prestazioni della farm. |
La dimensione massima predefinita del file è 250 MB. Questo limite è un limite configurabile che può essere aumentato fino a 2 GB (2.047 MB). Tuttavia, un volume elevato di file di grandi dimensioni può influire sulle prestazioni della farm. |
| Documenti |
30.000.000 per raccolta |
Supportato |
È possibile creare raccolte documenti di grandi dimensioni annidando cartelle o usando viste standard e gerarchia del sito. 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 |
| 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 |
30.000.000 per elenco |
Supportato |
È possibile creare elenchi di grandi dimensioni usando viste standard, gerarchie del sito e navigazione dei 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 ogni query, ad esempio tali valori in base alle colonne di ricerca, persona/gruppo o stato del flusso di lavoro. Se nella query vengono utilizzati più di otto join, l'operazione verrà bloccata. Questa condizione 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. Note: After applying the SharePoint Server 2013 cumulative update package released on August 13, 2013 (https://support.microsoft.com/kb/2817616), the default value is increased from 8 to 12. |
| Soglia visualizzazione elenco |
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. |
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. |
| 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. Nota: questa soglia deve essere abilitata usando il codice personalizzato per impostare SPQueryThrottleOption. |
| 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. |
| Creazione condivisa in Word, PowerPoint ed Excel per file di .docx, .pptx, ppsx e .xlsx |
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 di ambiti di sicurezza univoci per un elenco supera il valore della soglia di visualizzazione elenco (impostata per impostazione predefinita su 5.000 voci di elenco), quando viene visualizzato l'elenco vengono eseguiti altri round trip di SQL Server, che possono influire negativamente sulle prestazioni della visualizzazione 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. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server 2013. 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. |
Limiti relativi alle colonne
I dati di SharePoint Server 2013 vengono archiviati nelle 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 |
|
| Soglia |
255 |
Soglia |
30 byte |
|
| Soglia |
350 |
Soglia |
22 byte |
|
| Soglia |
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 |
| Soglia |
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" con 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 "ID", "Name" e "Description" del cliente. Nel complesso, queste colonne sono quelle che vengono aggiunte:
Colonna principale: un campo di testo.
Colonna ID nascosta: un campo di testo con più righe.
Colonne secondarie: ogni colonna secondaria è un testo, un numero, un valore booleano o un testo su più righe basato sul tipo di dati della colonna secondaria secondo quanto definito nel modello del Catalogo dati business. Ad esempio, l'ID potrebbe essere mappato a una colonna Number ; Il nome potrebbe essere mappato a una *singola riga di colonna di testo; La descrizione potrebbe essere mappata a più righe di colonna 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 |
Questo tipo non è un limite rigido, ma è coerente con le linee guida di Active Directory. Su tale valore influiscono diversi aspetti: 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 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 sono presenti molte voci (gruppi di sicurezza di utenti) nella raccolta siti (più di 1.000), è necessario usare PowerShell per gestire gli utenti anziché l'interfaccia utente. Questa piattaforma offrirà un'esperienza di gestione migliore. |
| Utenti/entità di Active Directory in un gruppo di SharePoint |
5.000 per 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. 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. Questa implicazione è particolarmente vera 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.
Nota
Limits for Search have changed significantly as the feature has been updated. For more information, see Plan search in SharePoint Server.
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. Per SharePoint Foundation 2013, questo limite è un componente di indice per ogni applicazione del servizio di ricerca e non può essere superato. |
| 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. 3 per partizione di indice |
| Supportato |
3 per partizione di indice |
Supportato |
Ogni partizione di indice può disporre di un set di repliche. Se si aumenta il numero di repliche di indice, questa modifica ha un effetto positivo sulle prestazioni della query e offre una migliore tolleranza di errore. Tuttavia, se si aggiungono troppe repliche alla partizione dell'indice, questo eccesso può influire negativamente sull'indicizzazione. Per gli scenari di siti Internet, che in genere hanno una frequenza di query elevata ma un volume di contenuto basso (meno di 4 milioni di elementi per partizione), il limite supportato è di sei repliche di indice per partizione. 1 per server |
| Componenti di elaborazione del contenuto |
1 per server |
Supportato |
La topologia di ricerca supporta la scalabilità orizzontale del numero di componenti di elaborazione del contenuto. Anche se un host fisico o una macchina virtuale specifica supporta più componenti di elaborazione del contenuto, è possibile ottenere un migliore utilizzo della capacità della CPU usando un componente di elaborazione del contenuto. 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 alimentazione consentono al componente di elaborazione del contenuto di elaborare i documenti in ingresso in parallelo. Questo meccanismo presuppone un singolo 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 avrà NK sessioni di alimentazione. K è un coefficiente costante con il valore iniziale 3. Un server a 4 core avrà 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 2013 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 avrà NK = 12 * 3 = 36 sessioni di alimentazione. Nel caso in cui il tempo di CPU sia ancora inattivo, è consigliabile aumentare il coefficiente K invece di aggiungere un componente aggiuntivo per l'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 |
Componenti di ricerca |
64 per applicazione del servizio di ricerca |
| Supportato |
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 verrà visualizzato un avviso che indica che il file ha superato la dimensione massima che il crawler può scaricare.
Se si cerca testo in un elemento e si ottengono solo risultati dalla prima parte del testo, il componente di elaborazione del contenuto potrebbe aver troncato l'elemento perché ha superato alcuni limiti di dimensioni dell'elemento. Quando il componente di elaborazione del contenuto tronca un elemento, indica questo troncamento 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.
| Tipo di limite | Note | Note | Note |
|---|---|---|---|
| Dimensioni dei documenti che il componente di ricerca per indicizzazione può scaricare |
64 MB (3 MB per documenti di Excel) |
Soglia |
La ricerca scarica i metadati e il contenuto da un documento 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. Eseguire questa modifica usando i cmdlet di Microsoft PowerShell per modificare la proprietà dell'applicazione del servizio di ricerca MaxDownLoadSize o MaxDownloadSizeExcel. La proprietà MaxDownLoadSize non influisce sulla dimensione massima dei documenti Excel. Immettere il volume in megabyte. Il valore relativo alle dimensioni massime del documento corrisponde a 1024 MB (anche per i documenti Excel). Se si aumenta il limite relativo alle dimensioni massime dei documenti, la ricerca indicizza più contenuto e richiede più spazio su disco. |
| Dimensioni del contenuto analizzato |
2 milioni di caratteri |
Limite |
La ricerca interrompe l'analisi di un elemento dopo che ha analizzato un massimo di 2 milioni di caratteri del relativo contenuto, inclusi gli allegati dell'elemento. La quantità effettiva di caratteri analizzati può essere inferiore a questo limite perché la ricerca impiega al massimo 30 secondi per analizzare un singolo elemento e i relativi allegati. Quando la ricerca smette di analizzare un elemento, questo viene contrassegnato come elaborato parzialmente. Il contenuto non analizzato non viene elaborato e pertanto non viene indicizzato. |
| Limite |
La ricerca scompone il contenuto in parole singole (token). Può perciò produrre fino a 1.000.000 di caratteri di un unico elemento, inclusi i relativi allegati. La quantità effettiva di caratteri elaborati può essere inferiore a questo limite perché la ricerca impiega al massimo 30 secondi per eseguire la scomposizione in parole. Il contenuto restante non viene elaborato e pertanto non viene indicizzato. |
Limite |
La ricerca scompone il contenuto in parole singole (token). Può perciò produrre fino a 1.000.000 di caratteri di un unico elemento, inclusi i relativi allegati. La quantità effettiva di caratteri elaborati può essere inferiore a questo limite perché la ricerca impiega al massimo 30 secondi per eseguire la scomposizione in parole. Il contenuto restante non viene elaborato e pertanto non viene indicizzato. |
| Dimensioni delle proprietà gestite indicizzate |
512 KB per proprietà gestita disponibile per la ricerca/disponibile per query |
Soglia |
Questa soglia è il valore predefinito per la dimensione massima 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. The maximum value for this maximum size is 2,097,152 bytes. 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 |
Questa soglia è il valore predefinito per le dimensioni massime di una proprietà gestita recuperabile. È 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. The maximum value for this maximum size is 2,097,152 bytes. Se si aumenta questo limite, si abilita l'indicizzazione di più dati per ogni proprietà gestita. 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. |
| Dimensioni delle proprietà gestite ordinabili e per affinamento ricerca |
16 KB per proprietà gestita |
Limite |
Questo limite è la dimensione massima di una proprietà gestita ordinabile e perfezionabile. |
| 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. I word 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. |
Ricerca: limiti relativi ai dizionari
I limiti del dizionario proteggono la memoria, l'efficienza di elaborazione del contenuto e i risultati delle query.
| Valore massimo | 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 limite limita il numero di termini consentiti per i dizionari inclusioni ed esclusioni per la correzione dell'ortografia 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, l'eccesso riduce la velocità di indicizzazione. |
| 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 |
1000 |
Proprietà dei metadati riconosciute |
Una proprietà gestita può disporre di più valori dello stesso tipo. Questa figura corrisponde al numero massimo di valori per ogni proprietà gestita gestita multivalore 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 è il numero massimo di proprietà dei metadati che il componente di ricerca per indicizzazione può determinare durante l'esecuzione di questo tipo di ricerca per un elemento. Queste proprietà possono essere mappate o utilizzate per le query. Se ci si avvicina a questo numero di proprietà sottoposte a ricerca per indicizzazione, la velocità di tale ricerca potrebbe diminuire. |
Ricerca: limiti relativi alla ricerca per indicizzazione
| 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 valore è quello testato e predefinito 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 |
| Numero di righe in un set di risultati |
500 righe |
Supportato |
Questo valore è quello testato e predefinito 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 invia una notifica all'utente finale. Questo è il limite testato per un'applicazione del servizio di ricerca con una combinazione di query degli utenti finali (75%) e query di avviso (25%). Il limite per un'applicazione del servizio di ricerca che dispone solo di query di avviso corrisponde a 400.000 avvisi. Questi limiti si basano su un sistema con cinque query al secondo (QPS). |
Ricerca: limiti relativi alla classificazione
I limiti relativi alla classificazione hanno la funzione di salvaguardare la memoria del server applicazioni, la latenza delle query e le dimensioni dell'indice.
| 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 è il numero massimo di contesti univoci per ogni modello di classificazione. |
| Pagine rilevanti |
1 pagina di livello principale e il minimo di pagine di secondo e terzo livello per applicazione del servizio di ricerca |
Supportato |
Usare il minor numero possibile di pagine di secondo e terzo livello per ottenere comunque la pertinenza desiderata. Il limite statico è 200 pagine rilevanti per livello di pertinenza per applicazione di ricerca. Se si aggiungono ulteriori pagine si potrebbe non ottenere la pertinenza desiderata. Aggiungere il sito chiave al primo livello di pertinenza. Aggiungere altri siti chiave al secondo o al terzo livello di pertinenza, uno alla volta. Valutare la pertinenza dopo ogni aggiunta per essere certi di raggiungere l'effetto desiderato. |
Ricerca: limiti relativi all'indice
I limiti relativi all'indice hanno la funzione di salvaguardare l'indice da un'espansione eccessiva e dal superamento delle risorse disponibili.
| Tipo di limite | Note | Note | 2^31 (2 miliardi di termini) |
|---|---|---|---|
| Termini univoci nell'indice |
2^31 (>2 miliardi di termini) |
Limite |
Questo è il numero massimo di termini univoci che possono essere presenti nell'indice di un'applicazione del servizio di ricerca. |
| Indici full-text definiti dall'utente |
10 |
Limite |
Questo è il numero massimo di indici full-text. |
| Elementi indicizzati |
In ogni partizione di indice è incluso un sottoinsieme dell'intero indice di ricerca. Se il numero degli elementi indicizzati è elevato rispetto alla quantità di memoria disponibile nel server, i tempi di risposta alle query si estenderanno. |
Nel caso di SharePoint Foundation 2013, il numero massimo di elementi indicizzati è pari a 2 milioni per ogni partizione di indicizzazione. |
In ogni partizione di indice è incluso un sottoinsieme dell'intero indice di ricerca. L'aggiornamento pubblico di giugno 2016 aumenta il limite a 10 milioni di elementi per partizione di indice. Limiti relativi al servizio profili utente For SharePoint Foundation 2013, the maximum number of indexed items is 2 million items per index partition, before applying the June 2016 Public Update. The June 2016 Public Update, increases this limit to 10 million items per index partition. |
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 è supportato al massimo un totale di 500 milioni tra tag di social networking, note e valutazioni senza ripercussioni significative sulle prestazioni. Le operazioni di manutenzione dei database, ad esempio il backup e il ripristino, potrebbero tuttavia risultare più lente. |
Limiti relativi alla distribuzione del contenuto
Nella tabella seguente sono riportate le linee guida consigliate per la distribuzione del contenuto.
| 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 di SQL Server per la distribuzione del contenuto, ogni percorso crea uno snapshot. This increases the I/O requirements for the source database. 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 valore massimo predefinito pari a 2.000 viene utilizzato dal connettore di database per limitare il numero di risultati che possono essere restituiti per pagina. L'applicazione può specificare un limite 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 tale soglia, le nuove richieste di attivazione di flussi di lavoro vengono accodate in modo da essere eseguite successivamente dal relativo servizio timer. Man mano che viene completata l'esecuzione senza servizio timer, le nuove richieste vengono conteggiate in relazione a questa soglia. Tale limite può essere configurato utilizzando il cmdlet Set-SPFarmConfig di PowerShell. Per altre informazioni, vedere Set-SPFarmConfig. Nota: questo limite non 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 ulteriori eventi, è possibile eseguire istanze aggiuntive del servizio timer flussi di lavoro di SharePoint Foundation. |
| Associazioni di flusso di lavoro |
100 per elenco |
Supportato |
Se si supera questo limite, le prestazioni del browser ne risentiranno a causa dell'elevato volume di dati che viene caricato per più di 100 associazioni e le relative colonne di stato. |
| Voci di elenco o documenti che possono essere creati o caricati in blocco per avviare le istanze di flusso di lavoro |
5.000 elementi |
Supportato |
Mediante i test è stato verificato che tutti gli eventi di attivazione dei flussi di lavoro vengono elaborati per un'associazione di flusso di lavoro al momento della creazione dell'elemento quando vengono creati fino a 5.000 elementi con un unico caricamento in blocco. Se si supera questo limite, può verificarsi un timeout dell'avvio del flusso di lavoro. |
| Definizioni di flusso di lavoro pubblicate per sito Web |
1.000 per sito Web |
Supportato |
Il numero massimo supportato di definizioni di flusso di lavoro pubblicate per ogni sito Web è 1.000. |
| Associazioni di flusso di lavoro totali per sito |
1.799 per sito |
Limite |
Il bus di servizio supporta un massimo di 1.799 sottoscrizioni per ogni ambito. Tale valore massimo include la somma delle associazioni pubblicate e non pubblicate. |
| Dimensioni massime delle definizioni di flusso di lavoro (XAML) |
5.120 KB |
Limite |
I tentativi di pubblicare file XAML che superano tali dimensioni avranno esito negativo. |
| Profondità massima di un passaggio secondario dei flussi di lavoro in XAML (complessità dei flussi di lavoro) |
121 livelli |
Limite |
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 |
Limite |
I test hanno confermato che un server Web SharePoint può attivare un massimo di 6 istanze di flusso di lavoro al secondo. Questo numero è cumulativo, pertanto varia in base al numero di server Web presenti nella farm. Ad esempio, 2 server Web possono attivare 12 istanze di flusso di lavoro al secondo, mentre 3 server Web possono attivarne 18. |
| Chiamate REST dal flusso di lavoro di SharePoint al secondo per server Web |
60 al secondo |
Supportato |
I test hanno confermato che un server Web SharePoint può elaborare efficacemente fino a 60 chiamate REST al secondo dal flusso di lavoro di SharePoint. Se questo volume viene superato, è consigliabile aggiungere alla farm di SharePoint un altro server Web con bilanciamento del carico. Durante il testing, 120 chiamate REST al secondo su un solo server Web hanno determinato un elevato utilizzo della CPU, pari al 90-100%. Aggiungendo un secondo server Web, l'utilizzo della CPU è sceso al 30-40% su entrambi i server. Aggiungendo un terzo server Web, è stato possibile elaborare 180 chiamate al secondo con un utilizzo della CPU pari al 30-40% su tutti e tre i server e così via. I server 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 di flusso di lavoro viene terminata. |
| Dimensioni massime degli elenchi per le ricerche dei flussi di lavoro in campi non indicizzati |
5.000 voci per visualizzazione elenco |
Soglia |
Questo limite è il risultato del limite massimo relativo alle dimensioni della visualizzazione. Quando tale limite viene superato, le ricerche dei flussi di lavoro in campi non indicizzati hanno esito negativo per gli utenti senza privilegi di amministratore. A questa soglia è possibile creare un indice per il campo, in modo che i flussi di lavoro possano eseguire correttamente le ricerche basate sul campo in questione. |
| Dimensioni massime degli elenchi per le associazioni di flusso di lavoro ad avvio automatico |
10 milioni di voci per elenco |
Supportato |
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 fino a 1 milione di elementi. Poiché il tempo di risposta resta invariato mentre le dimensioni degli elenchi cambiano, il limite effettivo corrisponde al numero massimo di voci presenti in un elenco non relativo a un flusso di lavoro. |
Limiti dei metadati gestiti
The following table lists the recommended guidelines for managed metadata configuration.
| Tipo di limite | Note | Note | Notes |
|---|---|---|---|
| Limite |
I metadati con impostazioni predefinite basate sulla posizione consentono di impostare valori predefiniti per colonne di elenco per cartella. È possibile applicare valori con impostazioni predefinite basate sulla posizione solo su un massimo di 1.000 cartelle per sito, o finché il file di dati in cui sono archiviati i metadati predefiniti basati sulla posizione per il sito (client_LocationBasedDefaults.html) raggiunge i 265 MB. |
Se nel file di dati sono presenti più di 1.000 cartelle o la dimensione del file di dati supera i 256 MB, i valori predefiniti inseriti per le cartelle aggiuntive verranno ignorati. |
I metadati con impostazioni predefinite basate sulla posizione consentono di impostare valori predefiniti per colonne di elenco per cartella. È possibile applicare valori con impostazioni predefinite basate sulla posizione solo su un massimo di 1.000 cartelle per sito, o finché il file di dati in cui sono archiviati i metadati predefiniti basati sulla posizione per il sito (client_LocationBasedDefaults.html) raggiunge i 265 MB. 1.000 collegamenti o dimensioni del file pari a 256 MB per documento |
| Limite |
Se un documento dotato di collegamenti viene aggiunto a una cartella, SharePoint Foundation 2013 aggiornerà automaticamente i collegamenti quando la loro destinazione viene spostata in una nuova posizione. In un documento con più di 1.000 collegamenti o in un documento di dimensioni superiori ai 256 MB, il documento viene considerato come se non contenesse collegamenti e gli aggiornamenti alle destinazioni dei collegamenti vengono ignorati per l'intero documento. |
Limiti relativi agli archivi termini (database) dei metadati gestiti |
When a document containing links is added to a folder, SharePoint Foundation 2013 will update links automatically when the link target is moved to a new location. In a document with more than 1,000 links, or a document with a file size that exceeds 256 Mb, the document is treated as though it contains no links, and updates to link targets are ignored for the entire document. |
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. Nota: sia il set di termini locale che il set di termini globale seguono il limite di 30.000 termini per sito di termini. Usare set di termini globali per archiviare i dati riutilizzabili per tutte le raccolte siti, anziché usare una grande quantità di set di termini per la raccolta siti o creare un nuovo servizio metadati gestiti. Un'applicazione Web può avere connessioni a più servizi. |
| 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. |
Vedere anche Panoramica del servizio metadati gestiti in SharePoint 2013 e L'impatto di più servizi metadati gestiti per farm
Limiti relativi a Visio Services
The following table lists the recommended guidelines for instances of Visio Services in SharePoint.
| Tipo di 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. Se si imposta un valore molto basso come validità minima della cache, diminuirà la velocità effettiva e aumenterà la latenza, in quanto un invalidamento troppo frequente della cache forza Visio a ripetere spesso i calcoli, con una conseguente riduzione della disponibilità della CPU e della memoria. |
| 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 della durata massima della cache su un valore molto 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 del servizio SharePoint Web Analytics
The SharePoint Web Analytics service has been deprecated in SharePoint Server 2013.
Limiti relativi a PerformancePoint Services
The following table lists the recommended guidelines for PerformancePoint Services in SharePoint.
| Tipo di 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 per cui viene utilizzata una cartella di lavoro di Excel come origine dati. Il numero di righe potrebbe cambiare in base al numero delle colonne. |
| Query su un elenco di SharePoint |
15 colonne per 5.000 righe |
Supportato |
Numero massimo di colonne e righe durante il rendering di qualsiasi oggetto dashboard di PerformancePoint per cui viene utilizzato un elenco di SharePoint come origine dati. Il numero di righe potrebbe cambiare in base al numero delle colonne. |
| Query su un'origine dati di SQL Server |
15 colonne per 20.000 righe |
Supportato |
Numero massimo di colonne e righe durante il rendering di qualsiasi oggetto dashboard di PerformancePoint per cui viene utilizzato una tabella di SQL Server come origine dati. Il numero di righe potrebbe cambiare in base al numero delle colonne. |
Limiti relativi a Word Automation Services
Nella tabella seguente sono riportate le linee guida consigliate per Word Automation Services.
| 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 ai livelli 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 un processo di conversione viene avviato utilizzando il metodo ConversionJob.Start, il processo e tutti gli elementi di conversione vengono trasmessi a un server applicazioni che quindi archivia il processo nel database di Word Automation Services. 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. I clienti non dovrebbero pertanto eseguire più processi di conversione di quanti sono i core di elaborazione disponibili nei server applicativi. Il processo timer di conversione e altre attività di SharePoint inoltre richiedono occasionalmente l'utilizzo di un core di elaborazione. È consigliabile lasciare sempre libero un core per l'utilizzo da parte del processo timer di conversione e di SharePoint. |
| Dimensioni del database di Word Automation Services |
2 milioni di elementi di conversione |
Supportato |
Word Automation Services mantiene una coda permanente di elementi di conversione nel proprio database. Ogni richiesta di conversione genera uno o più record. Word Automation Services non elimina automaticamente i record dal database, 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 a Excel Services
The following table lists the recommended guidelines for Excel Services in SharePoint.
| Tipo di limite | Note | Note | Notes |
|---|---|---|---|
| Supportato |
La dimensione massima di una cartella di lavoro che può essere aperta in Excel Services è pari a 10 MB. |
Limiti relativi al servizio di traduzione automatica |
The maximum size of a workbook that can be opened in Excel Services is 10 megabytes. |
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 Web Applications
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 |
Questo è il 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 a un utente sono assegnate più di 2.000 licenze, tale utente non potrà più vedere app nella visualizzazione Aggiungi un'app predefinita. Verrà invece visualizzato un messaggio in cui viene spiegato come effettuare ricerche nel catalogo app o in SharePoint Store. |
| Numero di app del catalogo aziendale visualizzabili da un singolo utente |
500 |
Limite |
Quando per un singolo utente sono disponibili più di 500 app del catalogo aziendale, tale utente non potrà più vedere app nella visualizzazione Aggiungi un'app predefinita. Verrà invece visualizzato un messaggio in cui viene spiegato come effettuare ricerche nel catalogo app o in SharePoint Store. |
Limiti relativi al servizio cache distribuita
Nella tabella seguente sono riportate le linee guida consigliate per il servizio cache distribuita.
| 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 della cache distribuita con 16 GB di RAM assegnati al servizio cache distribuita è pari a 400.000. |
| Numero di host della cache in un cluster |
16 |
Limite |
Il numero totale di host della cache che un singolo cluster di cache distribuita può supportare è pari a 16. |
| Massima quantità di memoria dedicata a un host della cache |
16 GB |
Limite |
La quantità totale di memoria che può essere dedicata al servizio cache distribuita in qualsiasi host della cache in un cluster è pari a 16 GB. |
Limiti vari
Nella tabella seguente sono riportati i limiti e le linee guida consigliate per servizi e funzionalità non trattati nelle altre sezioni.
| 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. |