Einschränkungen für Arbeitsnachverfolgung, Prozesse und Projekte
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018
In diesem Artikel werden Betriebs- und Objektbeschränkungen für Arbeitsnachverfolgungsvorgänge und Die Anpassung der Arbeitsnachverfolgung definiert. Neben den angegebenen harten Grenzwerten für ausgewählte Objekte gelten bestimmte praktische Grenzwerte. Berücksichtigen Sie beim Anpassen von Arbeitselementtypen (WITs) die Grenzwerte für Objekte.
Arbeitselemente und Abfragen
Beim Definieren von Arbeitselementen oder ausführen von Abfragen gelten die folgenden betriebsbedingten Grenzwerte.
| Object | Begrenzung |
|---|---|
| Anlagen, die einem Arbeitselement hinzugefügt wurden | 100 |
| Anlagengröße | 60 MB |
| Langes Textfeld | 1 M Zeichen |
| Abfrageausführungszeit | 30 Sekunden |
| Abfrageergebnisse | 20.000 Elemente |
| Abfragelänge | 32.000 Zeichen |
| Freigegebene Abfragen unter einem Ordner | 999 Abfragen |
| Einem Arbeitselement zugewiesene Arbeitselementlinks | 1\.000 |
| Arbeitselementtags, die einem Arbeitselement zugewiesen sind | 100 |
| Überarbeitungen von Arbeitselementen (REST-API) | 10.000 |
Für Updates, die über die REST-API für Azure DevOps Services vorgenommen werden, gilt ein Grenzwert für die Arbeitsaufgabenrevision von 10.000. Dieser Grenzwert schränkt Updates aus der REST-API ein, updates aus dem Webportal sind jedoch nicht betroffen.
| Object | Begrenzung |
|---|---|
| Langes Textfeld | 1 M Zeichen |
| Arbeitselementtags, die einem Arbeitselement zugewiesen sind | 100 |
| Einem Arbeitselement zugewiesene Arbeitselementlinks | 1\.000 |
| Anlagen, die einem Arbeitselement hinzugefügt wurden | 100 |
| Anlagengröße | 4 MB bis 2 GB |
| Abfrageausführungszeit | 6 Minuten |
| Abfrageergebnisse | 20.000 Elemente |
| Abfragelänge | 32.000 Zeichen |
| Freigegebene Abfragen unter einem Ordner | 999 Abfragen |
Die standardmäßige maximale Anlagengröße beträgt 4 MB. Sie können die maximale Größe bis zu 2 GB ändern.
Informationen zur Verbesserung der Abfrageleistung finden Sie unter Leitfaden zum Erstellen von Abfragen mit hoher Leistung.
Backlogs, Boards, Dashboards und Teams
Bei der Arbeit mit Teams, Arbeitselementtags, Backlogs und Boards gelten die folgenden Grenzwerte für die Betriebsanzeige und die Folgenden Objektgrenzwerte.
| Benutzeroberfläche | Begrenzung |
|---|---|
| Rückstände | 10.000 Arbeitselemente |
| Boards | 1.000 Karten (ohne diese Karten in den StatuskategorienVorgeschlagen und Abgeschlossen) |
| Task Board | 1.000 Aufgaben |
| Bereichspfade | 10.000 pro Organisation |
| Bereichspfadtiefe | 14 |
| Bereichspfade pro Team | 300 |
| Iterationspfade | 10.000 pro Organisation |
| Iterationspfadtiefe | 14 |
| Iterationspfade pro Team | 300 |
| Projektdashboards | 500 pro Projekt |
| Teamdashboards | 500 pro Team |
| Teams | 5.000 pro Projekt |
| Arbeitsaufgabentags | 150.000 Tagdefinitionen pro Organisation oder Sammlung |
| Übermittlungspläne pro Projekt | 1\.000 |
| Vorlagen pro Arbeitselementtyp | 100 |
Jedes Backlog kann bis zu 10.000 Arbeitselemente anzeigen. Dies ist ein Limit für die Anzeige des Backlogs, nicht ein Limit für die Anzahl der Arbeitselemente, die Sie definieren können. Wenn Ihr Backlog diesen Grenzwert überschreitet, sollten Sie in Erwägung ziehen, ein Team hinzuzufügen und einige der Arbeitselemente in das Backlog des anderen Teams zu verschieben.
Weitere Hinweise:
- Abgeschlossene oder geschlossene Arbeitselemente werden nicht auf den Backlogs und Boards angezeigt, sobald ihr Geändertes Datum größer als ein Jahr ist. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn sie in einem Backlog oder Board angezeigt werden sollen, können Sie eine geringfügige Änderung daran vornehmen, wodurch die Uhr für die Anzeige zurückgesetzt wird.
- Vermeiden Sie das Schachteln von Backlogelementen desselben Typs. Weitere Informationen finden Sie unter Beheben von Problemen beim Neuanordnen und Schachteln.
- Vermeiden Sie es, mehreren Teams dieselben Bereichspfade zuzuweisen. Weitere Informationen finden Sie unter Einschränkungen von Kanban-Boardansichten mit mehreren Teams.
- Standardmäßig können Grenzwerte für Arbeitselemente anfänglich so konfiguriert werden, dass die Werte gesenkt werden.
Bei der Arbeit mit Teams, Arbeitselementtags, Backlogs und Boards gelten die folgenden betriebsbedingten Grenzwerte. Standard- und Höchstgrenzwerte.
| Benutzeroberfläche | Begrenzung |
|---|---|
| Rückstände | 999 Arbeitselemente |
| Boards | 400 Karten |
| Dashboards pro Projekt | 500 |
| Task Board | 800 Arbeitselemente |
| Teams | 5.000 pro Projekt |
| Arbeitsaufgabentags | 150.000 Tagdefinitionen pro Projekt |
| Vorlagen pro Arbeitselementtyp | 100 |
Jedes Backlog kann bis zu 999 Arbeitselemente anzeigen. Wenn Ihr Backlog diesen Grenzwert überschreitet, sollten Sie in Erwägung ziehen, ein Team hinzuzufügen und einige der Arbeitselemente in das Backlog des anderen Teams zu verschieben.
Weitere Hinweise:
- Vermeiden Sie das Schachteln von Backlogelementen desselben Typs. Weitere Informationen finden Sie unter Beheben von Problemen beim Neuanordnen und Schachteln.
- Vermeiden Sie es, mehreren Teams dieselben Bereichspfade zuzuweisen. Weitere Informationen finden Sie unter Einschränkungen von Kanban-Boardansichten mit mehreren Teams.
Für das lokale XML-Prozessmodell können Sie die Backlog- und Taskboardgrenzwerte ändern, indem Sie die ProcessConfiguration.xml-Datei bearbeiten. Ausführliche Informationen finden Sie unter Xml-Elementreferenz für die Prozesskonfiguration.
Projekte
Azure DevOps Services jede Organisation auf 1.000 Projekte pro Organisation beschränkt, eine Steigerung gegenüber dem vorherigen Grenzwert von 300 Projekten.
Hinweis
Bei mehr als 300 Projekten können bestimmte Erfahrungen, z. B. das Herstellen einer Verbindung mit einem Projekt aus Visual Studio, möglicherweise beeinträchtigt werden. Für lokale Azure DevOps Server gibt es keine harten Grenzwerte für die Anzahl von Projekten. Sie können jedoch Leistungsprobleme feststellen, wenn sich die Anzahl der Projekte auf 300 annähert. Wenn Sie planen, Ihre lokale Sammlung zu Azure DevOps Services zu migrieren, müssen Sie den Höchstwert von 1.000 Projekten einhalten. Wenn Ihre Sammlung über mehr als 1.000 Projekte verfügt, müssen Sie entweder die Auflistung aufteilen oder ältere Projekte löschen.
Weitere Informationen finden Sie unter Migrieren von Daten von Azure DevOps Server zu Azure DevOps Services.
Prozessanpassung
Für die Anzahl der Objekte, die Sie für einen Prozess definieren können, werden eine Reihe von Grenzwerten festgelegt. Weitere Informationen zu Prozessmodellen finden Sie unter Anpassen der Arbeitsnachverfolgung.
In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für die Prozessmodelle Vererbung und gehostete XML definieren können. Diese stellen zwar harte Grenzwerte dar, können aber auch praktische Grenzwerte gelten.
| Object | Vererbung | Gehostete XML |
|---|---|---|
| Anzahl der Prozesse, über die Sie in einer Organisation verfügen können | 128 | 64 |
| Für einen Prozess definierte Arbeitselementtypen | 64 | 64 |
| Für eine Organisation definierte Felder | 8192 | 8192 |
| Für einen Prozess definierte Felder | 1024 | 1024 |
| Felder, die für einen Arbeitselementtyp definiert sind | 1024 | 1024 |
| Für eine Organisation oder Sammlung definierte Auswahllisten | 2048 | - |
| Picklistelemente, die für eine Liste definiert sind | 2048 | 2048 |
| Länge des Picklistelements | 256 | - |
| Workflowzustände, die für einen Arbeitselementtyp definiert sind | 32 | 16 |
| Für einen Arbeitselementtyp definierte Regeln | 1024 | 1024 |
| Für eine Regel definierte Aktionen | 10 | 10 |
| Für einen Prozess definierte Portfoliobacklogebenen | 5 | 5 |
| Für einen Prozess definierte Kategorien | - | 32 |
| Globale Listen, die für einen Prozess definiert sind | - | 256 |
| Listenelemente, die in einer globalen Liste definiert sind | - | 1024 |
| Größe des Arbeitselementanhangs | 60 MB | 60 MB |
Weitere Einschränkungen und Konformitätsanforderungen des gehosteten XML-Prozessmodells finden Sie unter Anpassen eines Prozesses bei Verwendung von gehostetem XML.
Hinweis
Für das gehostete XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die für alle WITs angegeben sind.
In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für das Vererbungs- und das lokale XML-Prozessmodell definieren können. Diese stellen zwar harte Grenzwerte dar, können aber auch praktische Grenzwerte gelten.
| Object | Vererbung | Lokales XML |
|---|---|---|
| Anzahl der Prozesse, über die Sie in einer Organisation verfügen können | 64 | 64 |
| Für einen Prozess definierte Arbeitselementtypen | 64 | 64 |
| Felder, die für eine Auflistung definiert sind | 8192 | 1024 |
| Für einen Prozess definierte Felder | 1024 | 1024 |
| Felder, die für einen Arbeitselementtyp definiert sind | 1024 | 1024 |
| Für eine Sammlung definierte Auswahllisten | 1024 | – |
| Picklistelemente, die für eine Liste definiert sind | 2048 | 2048 |
| Länge des Picklistelements | 256 | – |
| Workflowzustände, die für einen Arbeitselementtyp definiert sind | 32 | 16 |
| Für einen Arbeitselementtyp definierte Regeln | 1024 | 1024 |
| Für einen Prozess definierte Portfoliobacklogebenen | 5 | 5 |
| Für einen Prozess definierte Kategorien | – | 32 |
| Globale Listen, die für einen Prozess definiert sind | – | 256 |
| Listenelemente, die in einer globalen Liste definiert sind | – | 1024 |
Hinweis
Für das lokale XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die für alle WITs angegeben sind.
In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für das lokale XML-Prozessmodell definieren können. Diese stellen zwar harte Grenzwerte dar, doch können praktische Grenzwerte gelten.
| Object | Lokales XML |
|---|---|
| Anzahl der Prozesse, über die Sie in einer Organisation verfügen können | 64 |
| Für einen Prozess definierte Arbeitselementtypen | 64 |
| Felder, die für eine Auflistung definiert sind | 1024 |
| Für einen Prozess definierte Felder | 1024 |
| Felder, die für einen Arbeitselementtyp definiert sind | 1024 |
| Für eine Sammlung definierte Auswahllisten | – |
| Picklistelemente, die für eine Liste definiert sind | 2048 |
| Länge des Picklistelements | – |
| Workflowzustände, die für einen Arbeitselementtyp definiert sind | 16 |
| Für einen Arbeitselementtyp definierte Regeln | 1024 |
| Für einen Prozess definierte Portfoliobacklogebenen | 5 |
| Für einen Prozess definierte Kategorien | 32 |
| Globale Listen, die für einen Prozess definiert sind | 256 |
| Listenelemente, die in einer globalen Liste definiert sind | 1024 |
| Größe der importierten Prozessvorlage | 2 GB |
Hinweis
Für das lokale XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die für alle WITs angegeben sind.
Praktische Grenzen
Es wird empfohlen, die folgenden Anleitungen zu berücksichtigen, um Leistungsprobleme zu minimieren.
- Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten Felder. Alle benutzerdefinierten Felder tragen zur Gesamtsumme bei, die für einen Prozess, eine Sammlung oder eine Organisation zulässig ist. Beachten Sie, dass Sie ein anderes Verhalten für dasselbe Feld in einem anderen WIT angeben können. Das heißt, Sie können verschiedene Regeln, Auswahllisten usw. angeben.
- Minimieren Sie die Anzahl von Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn ein Benutzer Arbeitselemente hinzufügt und ändert. Wenn Benutzer Arbeitselemente speichern, überprüft das System alle Regeln, die den Feldern für den Arbeitselementtyp zugeordnet sind. Unter bestimmten Bedingungen ist der Regelüberprüfungsausdruck zu komplex, um SQL auszuwerten.
- Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten WITs.
- Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten Felder. Alle benutzerdefinierten Felder tragen zur Gesamtsumme bei, die für einen Prozess, eine Sammlung oder eine Organisation zulässig ist. Beachten Sie, dass Sie ein anderes Verhalten für dasselbe Feld in einem anderen WIT angeben können. Das heißt, Sie können verschiedene Regeln, Auswahllisten usw. angeben.
- Minimieren Sie die Anzahl von Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn ein Benutzer Arbeitselemente hinzufügt und ändert. Wenn Benutzer Arbeitselemente speichern, überprüft das System alle Regeln, die den Feldern für den Arbeitselementtyp zugeordnet sind. Unter bestimmten Bedingungen ist der Regelüberprüfungsausdruck zu komplex, um SQL auszuwerten.
- Minimieren Sie die Anzahl der von Ihnen definierten benutzerdefinierten WITs.
- Minimieren Sie die Anzahl der meldebaren Felder, die Sie definieren. Meldebare Felder wirken sich auf die Leistung Ihres Data Warehouses aus.
Hinweis
Überprüfung von Arbeitselementregeln überschreitet SQL-Grenzwerte: Pro Projekt wird ein einzelner SQL-Ausdruck definiert, um Arbeitselemente zu überprüfen, wenn sie erstellt oder aktualisiert werden. Dieser Ausdruck wächst mit der Anzahl von Regeln, die Sie für alle für das Projekt definierten Arbeitselementtypen angeben. Jeder für ein Feld angegebene Verhaltensqualifizierer führt zu einer Erhöhung der Anzahl von Unterausdrücken. Geschachtelte Regeln, Regeln, die nur für einen Übergang gelten oder auf den Wert eines anderen Felds bedingt sind, führen dazu, dass einer IF-Anweisung weitere Bedingungen hinzugefügt werden. Sobald der Ausdruck eine bestimmte Größe oder Komplexität erreicht, kann SQL ihn nicht mehr auswerten und generiert einen Fehler. Wenn Sie einige WITs entfernen oder einige Regeln entfernen, kann der Fehler behoben werden.
Ratenbegrenzungen
Um Kosten zu senken und Skalierbarkeit und Leistung zu verbessern, verwendet Azure DevOps Services, wie viele Software-as-a-Service-Lösungen, mehrinstanzenfähig. Um eine gute Leistung sicherzustellen und die Wahrscheinlichkeit von Ausfällen zu verringern, begrenzt Azure DevOps Services die Ressourcen, die Personen verbrauchen können, und die Anzahl der Anforderungen, die sie an bestimmte Befehle senden können. Wenn diese Grenzwerte überschritten werden, können nachfolgende Anforderungen entweder verzögert oder blockiert werden.
Die meisten Ratenlimits werden durch REST-API-Aufrufe oder nicht optimierte Abfragen erreicht. Weitere Informationen erhalten Sie in den folgenden Artikeln:
Migrations- und Importgrenzwerte
Wenn Sie eine Migration von einer lokalen zu einer Azure DevOps Services festlegen, gibt es möglicherweise mehrere Größenbeschränkungen. Zu diesen Grenzwerten gehören:
- Die Datenbankgröße liegt über der empfohlenen Größe.
- Die größte Tabellengröße liegt über der empfohlenen Größe.
- Die Größe der Datenbankmetadaten liegt über der unterstützten Größe.
Weitere Informationen finden Sie unter Migrieren von Daten von Azure DevOps Server zu Azure DevOps Services und Behandeln von Import- und Migrationsfehlern.