Einschränkungen für Arbeitsnachverfolgung, Prozesse und Projekte
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
In diesem Artikel werden Betriebs- und Objektbeschränkungen definiert, die für Arbeitsverfolgungsvorgänge und Anpassungen der Arbeitsnachverfolgung gelten. Zusätzlich zu den angegebenen harten Grenzwerten für bestimmte Objekte gelten einige praktische Grenzwerte. Wenn Sie Arbeitsaufgabentypen (Work Item Types, WITs) anpassen, sollten Sie die Grenzwerte berücksichtigen, die für Objekte gelten.
Arbeitsaufgaben und Abfragen
Beachten Sie beim Definieren von Arbeitsaufgaben oder beim Ausführen von Abfragen die folgenden betrieblichen Grenzwerte:
| Objekt | Begrenzung |
|---|---|
| Anlagen, die einer Arbeitsaufgabe 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 |
| Arbeitsaufgabenlinks, die einer Arbeitsaufgabe zugewiesen sind | 1.000 |
| Arbeitselementtags, die einer Arbeitsaufgabe zugewiesen sind | 100 |
| Überarbeitungen von Arbeitselementen (REST-API) | 10.000 |
| Favoritenabfragen pro Projekt | 200 Abfragen |
Die REST-API für Azure DevOps Services erzwingt eine Überarbeitungsgrenze von 10.000 Updates für Arbeitsaufgaben. Dieser Grenzwert beschränkt Updates, die über die REST-API vorgenommen wurden, aber Updates aus dem Webportal sind nicht betroffen.
| Objekt | Begrenzung |
|---|---|
| Langes Textfeld | 1-M-Zeichen |
| Arbeitselementtags, die einer Arbeitsaufgabe zugewiesen sind | 100 |
| Arbeitsaufgabenlinks, die einer Arbeitsaufgabe zugewiesen sind | 1.000 |
| Anlagen, die einer Arbeitsaufgabe 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 |
| Favoritenabfragen pro Projekt | 200 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 Definieren einer Abfrage/bewährter Methoden.
Backlogs, Boards, Dashboards und Teams
Wenn Sie mit Teams, Arbeitsaufgabentags, Backlogs und Boards arbeiten, gelten die folgenden Betriebsanzeige- und Objektgrenzwerte.
| User interface (Benutzeroberfläche) | Begrenzung |
|---|---|
| Rückstände | 10.000 Arbeitsaufgaben |
| Boards | 1.000 Karten (ausgenommen diese Karten in den Kategorien "Vorgeschlagen" und "Abgeschlossener Workflowstatus") |
| Task Board | 1.000 Vorgänge |
| Bereichspfade | 10.000 pro Projekt |
| Bereichspfadtiefe | 14 |
| Bereichspfade pro Team | 300 |
| Iterationspfade | 10.000 pro Projekt |
| Iterationspfadtiefe | 14 |
| Iterationspfade pro Team | 300 |
| Projektdashboards | 500 pro Projekt. Zugriff auf Projektebene und jeder, der Zugriff auf das Projekt hat, kann verwendet werden. |
| Teamdashboards | 500 pro Team. Spezifisch für das Team und verwendet, um teamspezifische Metriken und Daten nachzuverfolgen. |
| Teams | 5.000 pro Projekt |
| Arbeitsaufgabentags | 150.000 Tagdefinitionen pro Organisation oder Sammlung |
| Übermittlungspläne pro Projekt | 1.000 |
| Vorlagen pro Arbeitsaufgabentyp | 100 |
Jeder Backlog kann bis zu 10.000 Arbeitsaufgaben anzeigen. Dieser Grenzwert gilt für die Anzeige des Backlogs, nicht für die Anzahl der Arbeitsaufgaben, die Sie definieren können, da kein spezifischer Grenzwert vorhanden ist. Wenn Ihr Backlog diesen Grenzwert überschreitet, sollten Sie ein Team hinzufügen und einige Arbeitsaufgaben in den Backlog des neuen Teams verschieben.
Tipp
Wenn Sie den Grenzwerten für Dashboards nähern, lesen Sie die folgenden Schritte zum Verwalten und Bereinigen Ihrer Dashboards:
- Überprüfen Sie die Verwendung: Identifizieren Sie Dashboards, die nicht mehr verwendet werden oder Duplikate sind. Sie können dies tun, indem Sie das Datum des letzten Zugriffs überprüfen oder sich mit Teammitgliedern beraten.
- Konsolidieren Sie Dashboards: Kombinieren Sie ähnliche Dashboards, um die Gesamtanzahl zu reduzieren. Dazu können mehrere Widgets zu einem einzigen Dashboard hinzugefügt werden.
- Archivieren Sie alte Dashboards: Wenn bestimmte Dashboards nicht mehr benötigt werden, aber Sie die Daten beibehalten möchten, sollten Sie die Daten exportieren und die Dashboards archivieren.
- Verwenden Sie das Feature "Object Limit Tracker": Bietet Echtzeit-Einblicke in die Ressourcennutzung, einschließlich Dashboards. Dieses Feature kann Ihnen dabei helfen, Ihre Grenzwerte proaktiv zu verwalten und potenzielle Probleme zu vermeiden.
Weitere Hinweise:
- Abgeschlossene oder geschlossene Arbeitsaufgaben werden nicht auf Backlogs und Boards angezeigt, sobald ihr Geändertes Datum älter als ein Jahr ist. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Um sie auf einem Backlog oder Board anzuzeigen, nehmen Sie eine geringfügige Änderung vor, um die Anzeigeuhr zurückzusetzen.
- Vermeiden Sie das Verschachteln von Backlogelementen desselben Typs. Weitere Informationen finden Sie unter Beheben von Neuanordnungs- und Schachtelungsproblemen.
- Vermeiden Sie das Zuweisen derselben Bereichspfade zu mehreren Teams. Weitere Informationen finden Sie unter Einschränkungen von Ansichten mit mehreren Teamboards.
- Standardmäßig können Grenzwerte für Arbeitsaufgaben anfänglich auf niedrigere Werte festgelegt werden.
Wenn Sie mit Teams, Arbeitsaufgabentags, Backlogs und Boards arbeiten, gelten die folgenden betrieblichen Grenzwerte. Standard- und Maximalgrenzwerte.
| User interface (Benutzeroberfläche) | Begrenzung |
|---|---|
| Rückstände | 999 Arbeitsaufgaben |
| Boards | 400 Karten |
| Dashboards pro Projekt | 500 |
| Task Board | 800 Arbeitsaufgaben |
| Teams | 5.000 pro Projekt |
| Arbeitsaufgabentags | 150.000 Tagdefinitionen pro Projekt |
| Vorlagen pro Arbeitsaufgabentyp | 100 |
Jedes Backlog kann bis zu 999 Arbeitselemente anzeigen. Wenn Ihr Backlog diesen Grenzwert überschreitet, erwägen Sie, ein Team zu erstellen und einige der Arbeitsaufgaben in den Backlog des neuen Teams zu verschieben.
Weitere Hinweise:
- Vermeiden Sie das Verschachteln von Backlogelementen desselben Typs. Weitere Informationen finden Sie unter Beheben von Neuanordnungs- und Schachtelungsproblemen.
- Vermeiden Sie das Zuweisen derselben Bereichspfade zu mehreren Teams. Weitere Informationen finden Sie unter Einschränkungen von Ansichten mit mehreren Teamboards.
Für das lokale XML-Prozessmodell können Sie die Grenzwerte für den Backlog und das Taskboard ändern, indem Sie die ProcessConfiguration.xml Datei bearbeiten. Ausführliche Informationen finden Sie unter Prozesskonfigurations-XML-Elementreferenz.
Projekte
Azure DevOps Services schränkt jede Organisation auf 1.000 Projekte pro Organisation ein, eine Erhöhung gegenüber dem vorherigen Grenzwert von 300 Projekten.
Hinweis
Über 300 Projekte können bestimmte Erfahrungen, z. B. das Herstellen einer Verbindung mit einem Projekt aus Visual Studio, beeinträchtigt werden. Für lokale Azure DevOps Server gibt es keine harten Grenzwerte, aber Leistungsprobleme können auftreten, da die Anzahl der Projekte in der Nähe von 300 liegt. Beachten Sie beim Migrieren zu Azure DevOps Services die maximale Grenze von 1.000 Projekten. Wenn Ihre Sammlung diesen Grenzwert überschreitet, teilen Sie die Sammlung auf, oder löschen Sie ältere Projekte.
Weitere Informationen finden Sie unter Migrieren von Daten von Azure DevOps Server zu Azure DevOps Services.
Prozessanpassung
Viele Grenzwerte gelten für die Anzahl der Objekte, die Sie für einen Prozess definieren können. Weitere Informationen finden Sie unter Anpassen Ihrer Arbeitsverfolgungserfahrung.
Die folgende Tabelle enthält die maximale Anzahl von Objekten, die Sie für die Vererbungs- und gehosteten XML-Prozessmodelle definieren können. Während diese Grenzwerte hart sind, können auch praktische Grenzwerte gelten.
| Objekt | Vererbung | Gehostetes XML |
|---|---|---|
| Anzahl der Prozesse, die Sie in einer Organisation haben 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 Arbeitsaufgabentyp definiert sind | 1024 | 1024 |
| Für eine Organisation oder Sammlung definierte Auswahllisten | 2048 | - |
| Für eine Liste definierte Auswahllistenelemente | 2048 | 2048 |
| Länge des Auswahlelements | 256 | - |
| Für einen Arbeitselementtyp definierte Workflowstatus | 32 | 16 |
| Für einen Arbeitselementtyp definierte Regeln | 1024 | 1024 |
| Für einen Arbeitsaufgabentyp definierte Aktionen | 1024 | 1024 |
| Für eine Regel definierte Aktionen | 10 | 10 |
| Portfolio-Backlogebenen, die für einen Prozess definiert sind | 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 |
| Anlagengröße der Arbeitsaufgabe | 60 MB | 60 MB |
Weitere Einschränkungen und Konformitätsanforderungen des Gehosteten XML-Prozessmodells finden Sie unter Anpassen eines Prozesses bei Verwendung von Hosted XML.
Hinweis
Für das Gehostete XML-Prozessmodell können Sie ungefähr 10.000 Elemente für alle globalen Listen definieren, die in allen WITs angegeben sind.
In der folgenden Tabelle ist die maximale Anzahl von Objekten aufgeführt, die Sie für die Xml-Vererbungs- und lokalen XML-Prozessmodelle definieren können. Während diese Grenzwerte hart sind, können auch praktische Grenzwerte gelten.
| Objekt | Vererbung | Lokales XML |
|---|---|---|
| Anzahl der Prozesse, die Sie in einer Organisation haben 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 Arbeitsaufgabentyp definiert sind | 1024 | 1024 |
| Für eine Auflistung definierte Auswahllisten | 1024 | N/V |
| Für eine Liste definierte Auswahllistenelemente | 2048 | 2048 |
| Länge des Auswahlelements | 256 | N/V |
| Für einen Arbeitselementtyp definierte Workflowstatus | 32 | 16 |
| Für einen Arbeitselementtyp definierte Regeln | 1024 | 1024 |
| Portfolio-Backlogebenen, die für einen Prozess definiert sind | 5 | 5 |
| Für einen Prozess definierte Kategorien | N/V | 32 |
| Globale Listen, die für einen Prozess definiert sind | N/V | 256 |
| Listenelemente, die in einer globalen Liste definiert sind | N/V | 1024 |
Hinweis
Für das lokale XML-Prozessmodell können Sie eine ungefähre Gesamtsumme von 10K-Elementen für alle globalen Listen definieren, die für alle WITs angegeben sind.
Praktische Grenzwerte
Um Leistungsprobleme zu minimieren, empfehlen wir Die folgenden Anleitungen:
- Beschränken Sie die Anzahl der benutzerdefinierten Felder, die Sie definieren. Alle benutzerdefinierten Felder tragen zur Gesamtsumme bei, die für einen Prozess, eine Sammlung oder eine Organisation zulässig ist. Sie können für dasselbe Feld in verschiedenen WITs unterschiedliche Verhaltensweisen angeben, z. B. Regeln und Auswahllisten.
- Beschränken Sie die Anzahl der Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können andere Regeln sich negativ auf die Leistung auswirken, wenn Benutzer Arbeitsaufgaben hinzufügen oder ändern. Wenn Benutzer Arbeitsaufgaben speichern, überprüft das System alle Regeln, die den Feldern für diesen Arbeitsaufgabentyp zugeordnet sind. In einigen Fällen ist der Regelüberprüfungsausdruck möglicherweise zu komplex, damit SQL effizient ausgewertet werden kann.
- Beschränken Sie die Anzahl der benutzerdefinierten WITs, die Sie definieren.
- Beschränken Sie die Anzahl der benutzerdefinierten Felder, die Sie definieren. Alle benutzerdefinierten Felder tragen zur Gesamtsumme bei, die für einen Prozess, eine Sammlung oder eine Organisation zulässig ist. Sie können für dasselbe Feld in verschiedenen WITs unterschiedliche Verhaltensweisen angeben, z. B. Regeln und Auswahllisten.
- Beschränken Sie die Anzahl der Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können andere Regeln sich negativ auf die Leistung auswirken, wenn Benutzer Arbeitsaufgaben hinzufügen oder ändern. Wenn Benutzer Arbeitsaufgaben speichern, überprüft das System alle Regeln, die den Feldern für diesen Arbeitsaufgabentyp zugeordnet sind. In einigen Fällen ist der Regelüberprüfungsausdruck möglicherweise zu komplex, damit SQL effizient ausgewertet werden kann.
- Beschränken Sie die Anzahl der benutzerdefinierten WITs, die Sie definieren.
- Beschränken Sie die Anzahl der berichterstattungsfähigen Felder, die Sie definieren. Berichtbare Felder können sich auf die Leistung Ihres Data Warehouse auswirken.
Hinweis
Die Gültigkeitsprüfung von Arbeitsaufgabenregeln überschreitet SQL-Grenzwerte: Ein einzelner SQL-Ausdruck wird pro Projekt definiert, um Arbeitsaufgaben zu überprüfen, wenn sie erstellt oder aktualisiert werden. Dieser Ausdruck wächst mit der Anzahl der Regeln, die für alle Arbeitsaufgabentypen im Projekt angegeben sind. Jeder Verhaltensqualifizierer für ein Feld erhöht die Anzahl von Unterausdrücken. Geschachtelte Regeln, Regeln, die nur für einen Übergang gelten, oder Regeln, die auf den Wert eines anderen Felds bedingt sind, fügen einer IF-Anweisung weitere Bedingungen hinzu. Sobald der Ausdruck eine bestimmte Größe oder Komplexität erreicht hat, kann SQL ihn nicht mehr auswerten und einen Fehler generiert. Um diesen Fehler zu beheben, entfernen Sie einige WITs, oder entfernen Sie einige Regeln.
Ratenbegrenzungen
Um Kosten zu senken und Skalierbarkeit und Leistung zu verbessern, verwendet Azure DevOps Services wie viele Software-as-a-Service-Lösungen mehrinstanzenfähige Mandanten.To reduce costs and enhance skalierbarkeit and performance, Azure DevOps Services, like many software-as-a-Service solutions, uses multi-tenancy. Um eine gute Leistung sicherzustellen und das Risiko von Ausfällen zu minimieren, schränkt Azure DevOps Services die Ressourcen ein, die Einzelpersonen verbrauchen können, und die Anzahl der Anforderungen, die sie an bestimmte Befehle vornehmen können. Wenn diese Grenzwerte überschritten werden, werden nachfolgende Anforderungen möglicherweise verzögert oder blockiert.
Die meisten Geschwindigkeitsgrenzwerte werden über REST-API-Aufrufe oder nicht optimierte Abfragen erreicht. Weitere Informationen finden Sie unter "Rate limits" und "Best Practices" (to avoid hitting rate limits) (to avoid hitting rate limits).For more information, see Rate limits and Best Practices (to avoid hitting rate limits).For more information, see Rate limits and Best Practices (
Migrieren und Importieren von Grenzwerten
Bei der Migration von lokalen zu Azure DevOps Services können mehrere Größenbeschränkungen auftreten, darunter:
- Datenbankgröße, die die empfohlene Größe überschreitet
- Größte Tabellengröße, die die empfohlene Größe überschreitet
- Größe der Datenbankmetadaten, die die unterstützte Größe überschreitet
Weitere Informationen finden Sie unter Migrieren von Daten von Azure DevOps Server zu Azure DevOps Services und Problembehandlung bei Import- und Migrationsfehlern.