Azure limity poufnych rejestrów

Azure poufne rejestry ograniczają liczbę rejestrów w subskrypcji oraz dane, kod, użytkowników i role w każdym rejestrze, aby zapewnić przewidywalną wydajność i dostępność każdego rejestru. W tym artykule opisano te limity, sposób reagowania rejestru w przypadku przekroczenia żądania oraz oczekiwanej wydajności z rejestru.

Limity subskrypcji

Następujący limit dotyczy każdej subskrypcji Azure.

Limity danych rejestru

Następujące limity mają zastosowanie do każdego rejestru domyślnie.

• Kolekcje na rejestr: domyślna kolekcja nie jest liczone. Gdy rejestr osiągnie limit, zapisy, które spowodują utworzenie nowej kolekcji, zostaną odrzucone. Zapisy w istniejących kolekcjach nadal kończą się powodzeniem.
• Długość identyfikatora kolekcji: długość jest mierzona w bajtach zakodowanego identyfikatora UTF-8 po dekodowaniu adresu URL. Limit ma zastosowanie tylko wtedy, gdy zapis tworzy nową kolekcję, dzięki czemu można przechowywać zapis w kolekcjach utworzonych przed wprowadzeniem tego limitu i odczytywać je z kolekcji.
• Rozmiar zawartości wpisu rejestru: rozmiar jest mierzony w bajtach zakodowanej wartości UTF-8 contents po dekodowaniu JSON. Zawartość dokładnie 8192 bajtów jest akceptowana. Limit dotyczy zapisów zarówno dla nowych, jak i istniejących kolekcji. Identyfikator kolekcji, tagi i inne pola żądania nie są uwzględniane w tym limicie. Całe żądanie podlega również maksymalnemu rozmiarowi treści żądania rejestru.
• Tagi na rejestr: tag jest liczone raz dla każdej kolekcji, która z niej korzysta. Na przykład tag chocolate używany w dwóch kolekcjach jest liczone jako dwa tagi. Gdy rejestr osiągnie limit, zapisy, które dodałyby nowy tag do kolekcji, zostaną odrzucone. Zapisy bez tagów lub z tagami, których kolekcja już używa, nadal kończą się powodzeniem.

Zapis, który przekracza limit, jest odrzucany z kodem stanu HTTP 400 (nieprawidłowe żądanie) i nic w żądaniu nie jest zapisywane w rejestrze. Odpowiedź zawiera kod błędu i komunikat zawierający limit, który ma zastosowanie do rejestru. Na przykład:

{
  "error": {
    "code": "EntrySizeCapacityExceeded",
    "message": "Entry contents of 9000 bytes exceed the limit of 8192 bytes."
  }
}

Limity tagów na zapis

Tagi są obsługiwane tylko w publicznych rejestrach. Następujące limity dotyczą każdego publicznego rejestru.

Tagi nie mogą być puste i mogą zawierać tylko znaki A–Z, a–z, 0–9, -, _, .i ~. Zapis, który przekracza te limity lub zawiera nieprawidłowy tag, jest odrzucany z kodem stanu HTTP 400 i kodem błędu NotAllowed .

Limity użytkowników i ról

Następujące limity dotyczą użytkowników i ról niestandardowych w każdym rejestrze. Możesz dodawać użytkowników za pośrednictwem płaszczyzny sterowania Azure Resource Manager lub płaszczyzny danych rejestru, a każda ścieżka ma własne limity. Aby uzyskać więcej informacji na temat dwóch ścieżek, zobacz Wybieranie sposobu zarządzania użytkownikami w rejestrze poufnym Azure.

Te limity dotyczą tylko żądań, które dodają coś, takiego jak nowy użytkownik, przypisanie roli lub rola niestandardowa. Rejestr, który już przekracza limit, utrzymuje istniejących użytkowników i role, a oni nadal pracują. Nie można dodać więcej, dopóki rejestr nie zostanie ponownie osiągnięty poniżej limitu.

Podmioty zabezpieczeń dodane za pośrednictwem płaszczyzny sterowania

• Rejestr może mieć co najwyżej 1000 podmiotów zabezpieczeń dodanych przez płaszczyznę sterowania. Microsoft Entra podmioty zabezpieczeń (aadBasedSecurityPrincipals) i podmioty zabezpieczeń oparte na certyfikatach (certBasedSecurityPrincipals) są liczone do tego samego limitu.
• Aktualizacja płaszczyzny sterowania, która spowoduje dodanie podmiotu zabezpieczeń poza limit, kończy się niepowodzeniem z powodu błędu BadRequest . Szczegóły błędu zawierają komunikat Security principal limit reached: a ledger can have at most 1000 security principals. Jeśli aktualizacja dodaje kilka podmiotów zabezpieczeń i tylko niektóre z nich pasują, podmioty zabezpieczeń dodane przed osiągnięciem limitu zachowają swoje dotacje.
• Aktualizacja, która zmienia tylko rolę rejestru istniejących podmiotów zabezpieczeń, nie ma wpływu na ten limit.
• Usunięcie podmiotu z jednostki z późniejszej aktualizacji nie powoduje odwołania jego udzielenia, więc nie zwalnia miejsca. Aby usunąć udzielanie zarządzane przez płaszczyznę sterowania, skontaktuj się z pomoc techniczna platformy Azure. Aby uzyskać więcej informacji, zobacz Ograniczenia aktualizacji użytkowników płaszczyzny sterowania.

Użytkownicy i role zarządzane za pośrednictwem płaszczyzny danych

• Rejestr może mieć co najwyżej 1000 użytkowników dodanych przez płaszczyznę PATCH /app/ledgerUsers/{userId} danych za pomocą interfejsu API lub wcześniejszego PATCH /app/users/{userId} interfejsu API. Żądanie, które dodałoby nowego użytkownika poza limitem, zostanie odrzucone z kodem błędu UserCapacityExceeded . Ten limit nie blokuje żądań aktualizowania istniejących użytkowników i usuwania użytkownika zwalnia miejsce.
• Podmioty zabezpieczeń, które mają tylko przydział zarządzany przez płaszczyznę sterowania, nie są liczone do tego limitu. Podmiot zabezpieczeń rozpoczyna zliczanie podczas przypisywania ról za pośrednictwem płaszczyzny danych. Jeśli podmiot zabezpieczeń ma również przyznawanie zarządzane przez płaszczyznę sterowania, usunięcie płaszczyzny danych zwraca 409 ArmManagedUser i nie zwalnia miejsca. Po usunięciu przydziału zarządzanego płaszczyzną sterowania usunięcie płaszczyzny danych zwalnia miejsce.
• Użytkownik może mieć co najwyżej 103 role przypisane za pośrednictwem płaszczyzny danych, która jest wystarczająca dla wszystkich 100 ról niestandardowych i trzech wbudowanych ról. Żądanie, które przypisze więcej ról, zostanie odrzucone z kodem błędu UserRoleCapacityExceeded . Żądanie, które przypisuje tylko role, których użytkownik już nie ma, nie ma wpływu na ten limit. Role przypisane za pośrednictwem płaszczyzny sterowania nie są uwzględniane w tym limicie.
• Usunięcie roli niestandardowej nie powoduje usunięcia jej z użytkowników, którzy go mają, więc nadal jest liczone w kierunku ich limitu. Aby wyczyścić usunięte role od użytkownika, który ma tylko przyznawanie zarządzane przez płaszczyznę danych, usuń użytkownika i dodaj go ponownie z rolami, których potrzebuje.

Role niestandardowe

• Rejestr może mieć co najwyżej 100 ról niestandardowych. Wbudowane role Administrator, Współautor i Czytelnik nie są uwzględniane w tym limicie. Żądanie PUT /app/roles , które utworzyłoby rolę przekraczającą limit, zostanie odrzucone z kodem błędu RoleCapacityExceeded . Usunięcie roli zwalnia miejsce.
• Rola niestandardowa wymaga co najmniej jednej akcji i może mieć co najwyżej 200 akcji. PUT /app/roles odrzuca rolę bez akcji z kodem błędu InvalidInput oraz rolę z ponad 200 akcjami z kodem błędu RoleActionCapacityExceeded . PATCH /app/roles Sprawdza tylko dodane akcje, więc żądanie, które wysyła akcje, na które już ma rola, nie ma wpływu ten limit.
• Akcja może mieć długość co najwyżej 256 bajtów mierzoną w bajtach zakodowanej akcji UTF-8. Żądanie, które dodaje dłuższą akcję, jest odrzucane z kodem błędu InvalidInput .
• Żądanie PUT /app/roles , które przekracza dowolne z tych limitów, jest odrzucane jako całość i żadna z jej ról nie jest tworzona.

Żądanie płaszczyzny danych, które przekracza jeden z tych limitów, jest odrzucane z kodem stanu HTTP 400 i nic w żądaniu nie jest zapisywane w rejestrze. Odpowiedź zawiera kod błędu i komunikat zawierający limit. Na przykład:

{
  "error": {
    "code": "UserCapacityExceeded",
    "message": "User limit of 1000 reached."
  }
}

Limity funkcji zdefiniowanych przez użytkownika

Następujące limity dotyczą funkcji zdefiniowanych przez użytkownika (UDF) w każdym rejestrze. Żądania, które ich przekraczają, są odrzucane z kodem stanu HTTP 400.

Limity liczby i długości identyfikatorów funkcji zdefiniowanej przez użytkownika mają zastosowanie tylko podczas tworzenia funkcji zdefiniowanej przez użytkownika. Nadal możesz zaktualizować istniejącą funkcję zdefiniowaną przez użytkownika, jeśli jego kod mieści się w 64 KiB.

Aby zapoznać się z opcjami środowiska uruchomieniowego, które mają zastosowanie podczas uruchamiania funkcji zdefiniowanej przez użytkownika, zobacz Uruchamianie funkcji zdefiniowanych przez użytkownika. Aby uzyskać więcej informacji na temat wstępnych haków i punktów zaczepienia, zobacz Transakcje haki.

Opcje środowiska uruchomieniowego punktu końcowego zdefiniowanego przez użytkownika

Wartości ustawione za pomocą PATCH /app/userDefinedEndpoints/runtimeOptions muszą należeć do następujących zakresów. W przeciwnym razie żądanie zostanie odrzucone z kodem stanu HTTP 400 i kodem błędu InvalidInput . Sprawdzane są tylko opcje, których wartość zmienia żądanie.

Performance

Wydajność rejestru zależy od obciążenia, takiego jak rozmiar wpisów, liczba żądań wysyłanych współbieżnie oraz kombinacja odczytów i zapisów. Poniższe wskazówki zawierają ogólne pojęcie o tym, czego można się spodziewać. To nie jest gwarancja.

Produktywność

• Rejestr może utrzymywać setki zapisów na sekundę. Mniejsze wpisy i więcej współbieżnych żądań zwiększają szybkość. Zapisy, które uruchamiają funkcje zdefiniowane przez użytkownika, trwa dłużej, w zależności od kodu funkcji.
• Odczytywanie najnowszego wpisu kolekcji zużywa mniej zasobów niż zapis, więc rejestr może zwykle obsługiwać więcej tych żądań. Pobieranie wpisu według identyfikatora transakcji, uzyskiwanie potwierdzenia i zapytania zakresu używają większej ilości zasobów niż odczytywanie najnowszego wpisu, ponieważ rejestr najpierw ładuje dane z magazynu. Duża liczba tych żądań zmniejsza przepływność pozostawioną dla operacji zapisu.
• Klient, który czeka na każdą odpowiedź, zanim wyśle następne żądanie, jest ograniczony przez czas rundy do rejestru. Aby jak najlepiej wykorzystać rejestr, wyślij żądania współbieżnie i ponownie użyj połączeń.

Jeśli obciążenie wymaga stałej wysokiej przepływności, przetestuj ją w rejestrze przed przejściem do środowiska produkcyjnego. Jeśli potrzebujesz większej przepływności, skontaktuj się z pomoc techniczna platformy Azure.

Opóźnienie

• Domyślnie żądanie zapisu jest zwracane natychmiast po zaakceptowaniu zapisu przez rejestr, a rejestr zatwierdza zapis wkrótce po. Przed rozpoczęciem polegania na zapisie, na przykład w celu uzyskania potwierdzenia, sprawdź, czy jego stan to Committed. Biblioteki klienckie mogą czekać na zatwierdzenie.
• Uzyskanie wpisu według identyfikatora transakcji, uzyskanie potwierdzenia i zapytania zakresu mogą być zwracane Loading jako pierwsze, podczas gdy rejestr ładuje dane. Powtórz żądanie w ciągu jednej minuty, aż zwróci wynik.
• Opóźnienie zależy również od odległości i obciążenia. Każde nowe połączenie wymaga uzgadniania protokołu TLS z rejestrem, więc użyj ponownie połączeń i uruchom klientów w pobliżu regionu rejestru. Spodziewaj się wzrostu opóźnienia, gdy obciążenie rejestru zbliża się do tego, co może utrzymać.

Treści powiązane

• Wybieranie sposobu zarządzania użytkownikami w rejestrze poufnym Azure
• Organizacja danych
• Funkcje zdefiniowane przez użytkownika
• Punkty końcowe zdefiniowane przez użytkownika
• Zapisywanie potwierdzeń transakcji