Azure limity poufnych rejestrów

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

Note

Limity w tym artykule są domyślne. W niektórych przypadkach pojedynczy rejestr może mieć różne limity, na przykład rejestr utworzony przed wprowadzeniem limitu. Aby zażądać wyższych limitów lub omówić ograniczenia, skontaktuj się z pomoc techniczna platformy Azure.

Limity subskrypcji

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

Limit Value
Rejestry na subskrypcję 2

Limity danych rejestru

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

Limit Wartość domyślna Kod błędu
Kolekcje na rejestr 5,000 CollectionCapacityExceeded
Długość identyfikatora kolekcji 256 bajtów CollectionIdTooLong
Rozmiar zawartości wpisu rejestru 8 KiB (8192 bajty) EntrySizeCapacityExceeded
Tagi na rejestr (tylko rejestry publiczne) 10,000 TagCapacityExceeded
  • 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.

Limit Value
Tagi na zapis 5
Długość tagu 63 znaki

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 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.

Limit Value Kod błędu
Funkcje zdefiniowane przez użytkownika na rejestr 100 UserDefinedFunctionCapacityExceeded
Długość identyfikatora UDF 256 bajtów InvalidFunctionId
Rozmiar kodu UDF 64 KiB (65 536 bajtów) InvalidInput
Wstępne haki na zapis 5 InvalidInput
Haki po zapisie 5 InvalidInput

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.

Opcja środowiska uruchomieniowego Dozwolone wartości
max_heap_bytes Do 209 715 200 (200 MiB)
max_stack_bytes Od 1 do 10 485 760 (10 MiB)
max_execution_time_ms Do 10 000 (10 sekund)
max_cached_interpreters Od 1 do 20

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

  • Ostatnia aktualizacja o