Guardrails: Performance-Grenzwerte für Jira Data Center

Leitplanken sind passive Schutzeinrichtungen entlang von Straßen, die verhindern sollen, dass Fahrzeuge von der Fahrbahn abkommen. Im Fall der Fälle sorgen sie dafür, dass hoffentlich nichts Schlimmeres als ein materieller Schaden entsteht: Es gibt ein paar Kratzer, aber mit etwas Glück kann man gegenlenken und in die Spur zurückfinden.

Vor einiger Zeit hat Atlassian für Jira und Confluence in den Data-Center-Ausführungen sogenannte Guardrails veröffentlicht. Dabei handelt es sich um "Performance-Leitplanken" – obwohl "Grenzwerte" vielleicht eine besser passende Formulierung wäre.

Hintergrund: Große Atlassian-Systeme, ihre Performance und die Guardrails

Wenn eine Atlassian-Instanz in einer großen Organisation wächst, steigt mit der Zeit auch das Risiko, dass es zu Herausforderungen im Hinblick auf die Performance kommt. Das drückt sich häufig in Form einer graduellen, schleichenden Verschlechterung aus: Sie wird übersehen oder nicht beachtet, bis ein Punkt erreicht ist, an dem die negativen Auswirkungen deutlich sind und nicht mehr ignoriert werden können.

Jira Data Center GuardrailsIm Kern sind die Atlassian-Guardrails strategische Empfehlungen, die Admin-Teams großer Data-Center-Instanzen helfen sollen, potenzielle Performance-Kipppunkte in den Fokus zu rücken und gegebenenfalls gegensteuern zu können, um Risiken zu minimieren.

Sie basieren auf tatsächlichen Erfahrungen großer Atlassian-Kunden und können als Maximal-Richtwerte dienen, ohne notwendigerweise repräsentativ für alle Unternehmen zu sein. Es handelt sich also nicht um exakte, starre Limits oder um unverrückbare Grenzen. Manche Instanzen haben die unten aufgeführten Werte längst überschritten und funktionieren reibungslos.

Es gibt etliche Faktoren, unter anderem das Zusammenspiel unterschiedlicher Datentypen und die Instanz-Last, die Einfluss darauf haben, ob und in welchem Umfang Performance-Auswirkungen spürbar werden. Aber wie bei allen Arten von Risiken ist es wichtig, sie überhaupt erstmal zu identifizieren und dann einen Plan zu erstellen, damit das Team seine Aktivitäten priorisieren und somit die Wahrscheinlichkeit künftiger Performance-Probleme reduzieren kann.

Grundsätzliche Strategien für eine stabile Performance

Bevor wir zu den einzelnen Guardrails kommen, wollen wir kurz einige allgemeine Herangehensweisen im Hinblick auf die Performance großer Data-Center-Systeme rekapitulieren. Es gibt Wege, das Risiko ernsthafter Performance- und Stabilitätsprobleme grundsätzlich zu senken:

  • Änderungen an der Applikation: Regelmäßige Updates auf aktuelle Versionen sind für Data-Center-Instanzen Pflicht. Die Atlassian-Entwicklungsteams drehen kontinuierlich an den Performance-Stellschrauben der Produkte und liefern regelmäßig Verbesserungen und Optimierungen aus, die sich auf die Systemleistung auswirken.
  • Änderungen der Infrastruktur: Die Erhöhung des Speichers und der CPU-Leistung trägt ebenso zu einer guten, stabilen Performance bei wie der Betrieb in einem Cluster oder die Nutzung von Spiegel-Servern.
  • Aktivitäten zur Datenbereinigung wie die Archivierung veralteter Inhalte oder das Aufbrechen extrem großer Instanzen in kleinere reduzieren die Belastung des Systems und sind bewährte Rezepte.

Guardrails für Jira

Neben solchen allgemeinen Maßnahmen benennt Atlassian diverse Einflussfaktoren und reichert sie mit konkreten Richtwerten an. Dies sind die wichtigsten Guardrails für Jira Data Center:

Nutzer

Wenn es um die Performance einer Atlassian-Instanz geht, haben viele Leute wohl als erstes die Anzahl der Nutzer im Kopf. Atlassian benennt diesbezüglich einen Grenzwert von 100.000 Usern, die zwischen LDAP und dem Atlassian-System synchronisiert werden.

Hier gibt es mehrere Optionen, um die Last zu verringern. Atlassian Crowd oder Microsoft Active Directory bieten die Möglichkeit der inkrementellen Synchronisation. Dabei werden lediglich die Änderungen seit der letzten Synchronisation eingephast. Falls Crowd Server im Einsatz ist, sollte das Admin-Team den Umstieg auf Crowd Data Center anpeilen, um eine Access-basierte Synchronisation zu ermöglichen. Weiterhin können LDAP-Filter helfen, die Anzahl der Nutzer und Gruppen zu reduzieren, die in der Instanz zu verarbeiten sind.

Inaktive User

Neben den aktiven Usern können auch die inaktiven Nutzer, die mit Inhalten verknüpft sind, Auswirkungen auf die Performance haben, insbesondere wenn es sich um eine ältere Version von Jira Data Center handelt. Die Schwelle liegt ebenfalls bei 100.000. Admins können gegensteuern, indem sie inaktive User, denen Content zugewiesen ist, entfernen und dann eine Synchronisation durchführen, um die inaktiven Nutzer aus dem Verzeichnis zu entfernen.

Projekte

Der kritische Wert für aktive Projekte über die Instanz hinweg liegt Atlassian zufolge bei 7.000. In Jira Data Center haben Admins die Option, nicht mehr benötigte Projekte zu archivieren – und bei 7.000 und mehr Projekten im System ist die Wahrscheinlichkeit hoch, dass etliche davon seit langer Zeit inaktiv sind.

Eine sinnvolle Jira-Archivierungsstrategie besteht darin, Ablaufdaten zu definieren, die Projekte nach dem Überschreiten zu überprüfen und sich mit den Projekt-Ownern abzustimmen. Wenn es in einem Projekt ein Jahr lang keine Änderungen gegeben hat, liegt die Vermutung nahe, dass es nicht mehr benötigt wird. (Archivierte Projekte sind nicht gelöscht, sondern lassen sich jederzeit wiederherstellen.)

Epics

Hier bewegt sich der Grenzwert bei 100.000 Epics in der Instanz, also eine ganze Menge. Aber auch dieser Wert wird in manchen großen Systemen mit der Zeit geknackt. Die Archivierung von Projekten ist in diesem Zusammenhang ebenfalls ein gutes Gegenmittel, um die Zahl der aktiven Epics zu verringern.

Sprints

Ab 60.000 Sprints im Gesamtsystem müssen Admins mit Performance-Problemen rechnen. Deshalb ist es ein gutes Rezept, regelmäßig geschlossene und alte Sprints, die nicht mehr benötigt werden, zu löschen. Dafür gibt es eine praktische REST-API-Operation.

Custom Fields

Erfahrene Jira-Administratoren wissen, wie hilfreich Custom Fields sind – und welche Gefahren mit der intensiven Verwendung einhergehen können. Der Grenzwert liegt bei 1.200 Custom Fields pro Instanz. Viele große, stark genutzte Systeme erreichen diese Anzahl mit der Zeit.

Wenn dies der Fall ist, lohnt es sich, die Custom-Field-Nutzung zu analysieren und zu optimieren. Beispielsweise weisen zahlreiche Custom Fields einen globalen Kontext auf, obwohl die Felder nur in einigen wenigen Projekten eingesetzt werden.

Kommentare

Der Grenzwert von 1.000 Kommentaren bezieht sich nicht auf die Gesamtheit, sondern auf die Kommentare zu einem einzelnen Vorgang. Zwar dürfte es eine Ausnahme sein, dass einzelne Vorgänge derart viele Kommentare aufweisen, aber in Projekten mit vielen Beteiligten und vielen Automatisierungen kommt das durchaus vor.

Es lohnt sich also, nach Issues mit sehr vielen Anmerkungen Ausschau zu halten. Oft sind laxe Automatisierungsregeln dafür verantwortlich, dass Vorgänge mit (oft unwichtigen) Kommentaren geflutet werden. Auch die Nutzung der nativen Ratenbegrenzung kann hier hilfreich sein.

Anhänge

Viele Attachments können sich ebenfalls negativ auswirken. Die Schwelle liegt bei 1.000 Anhängen pro Vorgang, wobei einzelne Anhänge die Größe von 10 MB nicht überschreiten sollten. Amins haben die Option, eine Maximalgröße für Dateien festzulegen. Auch hier kann die Recherche nach ungünstig konfigurierte Automatisierungen Abhilfe schaffen. Außerdem kann es nützlich sein, die Thumbnails für Anhänge zu deaktivieren und die Attachments in archivierten Projekten ebenfalls explizit zu archivieren.

Weitere Grenzwerte

  • Gruppen: 25.000
  • Tiefe von Nested Groups: vier Ebenen
  • Text: 255 Zeichen für einzeilige Felder, 10.000 Zeichen für mehrzeilige Felder
  • Issue-Links: 1.000 pro Vorgang
  • Workflow-Schema Bulk-Aktionen: Aktualisierung von 1.000 Vorgängen gleichzeitig (bereits nativ so begrenzt)
  • Änderungshistorie: 20.000 Änderungseinträge für einen Vorgang

Guardrails als ständige Checks etablieren

Welche Herangehensweise ist für nun Administratoren zielführend? Falls das Jira-System bereits Performance-Probleme aufweist, ist es sicherlich ratsam, die Instanz explizit auf erreichte Grenzwerte zu untersuchen und Schritt für Schritt Gegenmaßnahmen einzuleiten.

Ansonsten besteht eine gute Strategie darin, bei regelmäßig anfallenden Wartungsarbeiten stets die Guardrails auf dem Radar zu haben und darauf hinzuarbeiten, dass die Grenzwerte gar nicht erst erreicht werden. Beispielsweise sind eine regelmäßige Archivierung und ein systematisches Nutzermanagement hilfreich, um möglichst eine dauerhaft stabile Performance zu gewährleisten.

Dein Partner für Atlassian Data Center

Möchtest du mehr darüber wissen, wie Atlassian Data Center deine Organisation beim Skalieren unterstützt? Als Atlassian Platinum Solution Partner mit Erfahrungen aus tausenden Atlassian-Projekten beraten wir dich bei der Evaluation eines optimalen Lizenzmodells, helfen bei einer reibungsarmen Umstellung von Atlassian Server auf Data Center und unterstützen dein Unternehmen bei allen Aspekten der Skalierung der Atlassian-Produkte. Melde dich bei uns!

Weiterführende Infos

Wie Atlassian Data Center bei der Vermeidung von Downtimes hilft
Atlassian Data Center: Performance-Verbesserung durch neue Cleanup-Features
Schutz, Compliance und Sichtbarkeit: Erweiterte Auditierung für Atlassian Data Center
Atlassian Data Center: Jetzt auch ohne Clustering möglich und in zwei Minuten eingerichtet

Artikelbild von Naomi August unter Unsplash-Lizenz

Diese Jira-Schulung richtet sich an erfahrene User, die tiefergehende Funktionen in Jira erlernen und Best Practices zum Vorgangsmanagement erlernen wollen.