Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
gizli kayıt defteri Azure, her bir kayıt defterinin performansını ve kullanılabilirliğini tahmin edilebilir tutmak için abonelikteki kayıt defterlerinin sayısını ve bir kayıt defterinin depodüğü veri ve kodu sınırlar. Bu makalede bu sınırlar, bir istek aşıldığında kayıt defterinin nasıl yanıt verdiği ve bir kayıt defterinden hangi performansın bekleyebileceğiniz açıklanır.
Note
Bu makaledeki sınırlar varsayılandır. Belirli durumlarda, tek bir kayıt defterinin farklı sınırları olabilir; örneğin, bir sınır uygulanmadan önce oluşturulmuş bir kayıt defteri. Daha yüksek sınırlar istemek veya sınırlamaları tartışmak için Azure desteği başvurun.
Abonelik sınırları
Aşağıdaki sınır her Azure aboneliği için geçerlidir.
| Limit | Değer |
|---|---|
| Abonelik başına kayıt defterleri | 2 |
Kayıt defteri veri sınırları
Aşağıdaki sınırlar varsayılan olarak her kayıt defteri için geçerlidir.
| Limit | Varsayılan değer | Hata kodu |
|---|---|---|
| Kayıt defteri başına koleksiyonlar | 5.000 | CollectionCapacityExceeded |
| Koleksiyon Kimliği uzunluğu | 256 bayt | CollectionIdTooLong |
| Defter girişinin içeriğinin boyutu | 8 KiB (8.192 bayt) | EntrySizeCapacityExceeded |
| Kayıt defteri başına etiketler (yalnızca genel defterler) | 10.000 | TagCapacityExceeded |
- Kayıt defteri başına koleksiyon sayısı: Varsayılan koleksiyon sayılmaz. Bir kayıt defteri sınıra ulaştığında, yeni koleksiyon oluşturacak yazma işlemleri reddedilir. Mevcut koleksiyonlara yazma işlemi yine başarılı olur.
- Koleksiyon Kimliği uzunluğu: UZUNLUK, URL kod çözmeden sonra UTF-8 kodlanmış kimliğinin bayt cinsinden ölçülür. Sınır yalnızca yazma işlemi yeni bir koleksiyon oluşturduğunda geçerlidir, böylece bu sınır kullanılmadan önce oluşturulan koleksiyonlara yazmaya ve koleksiyonlardan okumaya devam edebilirsiniz.
-
Kayıt defteri girişinin içeriğinin boyutu: Boyut, JSON kod çözmeden sonra UTF-8 kodlanmış
contentsdeğerinin bayt cinsinden ölçülür. Tam olarak 8.192 baytlık içerik kabul edilir. Sınır, hem yeni hem de mevcut koleksiyonlara yazma işlemleri için geçerlidir. İsteğin koleksiyon kimliği, etiketleri ve diğer alanları bu sınıra doğru sayılmaz. İsteğin tamamı, kayıt defterinin maksimum istek gövdesi boyutuna da tabidir. -
Kayıt defteri başına etiketler: Etiketi kullanan her koleksiyon için bir kez sayılır. Örneğin, iki koleksiyonda kullanılan etiket
chocolateiki etiket olarak sayılır. Bir kayıt defteri sınıra ulaştığında, koleksiyona yeni etiket ekleyecek yazma işlemleri reddedilir. Etiketler olmadan veya koleksiyonun zaten kullandığı etiketlerle yazma işlemi yine başarılı olur.
Sınırı aşan yazma işlemi HTTP durum kodu 400 (Hatalı İstek) ile reddedilir ve istekteki hiçbir şey kayıt defterine yazilmez. Yanıt, hata kodunu ve kayıt defteri için geçerli olan sınırı içeren bir ileti içerir. Örneğin:
{
"error": {
"code": "EntrySizeCapacityExceeded",
"message": "Entry contents of 9000 bytes exceed the limit of 8192 bytes."
}
}
Yazma başına etiket sınırları
Etiketler yalnızca genel kayıt defterlerinde desteklenir. Aşağıdaki sınırlar her genel muhasebe için geçerlidir.
| Limit | Değer |
|---|---|
| Yazma başına etiketler | 5 |
| Etiket uzunluğu | 63 karakter |
Etiketler boş olamaz ve yalnızca –Z, –, a–-z9, 0, , _.ve ~karakterlerini Aiçerebilir. Bu sınırları aşan veya geçersiz etiket içeren yazma işlemi HTTP durum kodu 400 ve NotAllowed hata koduyla reddedilir.
Kullanıcı tanımlı işlev sınırları
Aşağıdaki sınırlar her kayıt defterindeki kullanıcı tanımlı işlevler (UDF) için geçerlidir. Bunları aşan istekler HTTP durum kodu 400 ile reddedilir.
| Limit | Değer | Hata kodu |
|---|---|---|
| Kayıt defteri başına UDF'ler | 100 | UserDefinedFunctionCapacityExceeded |
| UDF kimlik uzunluğu | 256 bayt | InvalidFunctionId |
| UDF kod boyutu | 64 KiB (65.536 bayt) | InvalidInput |
| Yazma başına ön kancalar | 5 | InvalidInput |
| Yazma başına kanca sonrası | 5 | InvalidInput |
UDF sayısı ve kimlik uzunluğu sınırları yalnızca UDF oluşturduğunuzda geçerlidir. Kodu 64 KiB'a sığıyorsa mevcut UDF'yi güncelleştirmeye devam edebilirsiniz.
UDF çalıştırıldığında uygulanan çalışma zamanı seçenekleri için bkz. UDF'leri çalıştırma. Ön kancalar ve kanca sonrası hakkında daha fazla bilgi için bkz. İşlem kancaları.
Kullanıcı tanımlı uç nokta çalışma zamanı seçenekleri
ile PATCH /app/userDefinedEndpoints/runtimeOptions ayarlanan değerler aşağıdaki aralıklar içinde olmalıdır. Aksi takdirde istek HTTP durum kodu 400 ve InvalidInput hata koduyla reddedilir. Yalnızca isteğin değeri değişen seçenekler denetleniyor.
| Çalışma zamanı seçeneği | İzin verilen değerler |
|---|---|
max_heap_bytes |
En fazla 209.715.200 (200 MiB) |
max_stack_bytes |
1 - 10.485.760 (10 MiB) |
max_execution_time_ms |
En fazla 10.000 (10 saniye) |
max_cached_interpreters |
1 - 20 |
Performance
Kayıt defterinin performansı, girdilerinizin boyutu, eşzamanlı olarak kaç istek gönderdiğiniz ve okuma ve yazmaların karışımı gibi iş yükünüze bağlıdır. Aşağıdaki kılavuz, neler bekleyebileceğiniz hakkında genel bir fikir verir. Bu bir garanti değil.
Throughput
- Kayıt defteri saniyede yüzlerce yazma işlemine devam edebilir. Daha küçük girişler ve daha fazla eşzamanlı istek oranı artırır. İşlevlerin koduna bağlı olarak, kullanıcı tanımlı işlevleri çalıştıran yazma işlemleri daha uzun sürer.
- Bir koleksiyonun en son girdisini okumak yazma işlemine göre daha az kaynak kullandığından, kayıt defteri genellikle bu isteklerden daha fazlasını sağlayabilir. Kayıt defteri ilk olarak verileri depolama alanından yüklediğinden, işlem kimliğine göre giriş alma, alındı bilgisi alma ve aralık sorguları en son girişi okumaktan daha fazla kaynak kullanır. Bu isteklerin yüksek bir oranı, yazma işlemleri için kalan aktarım hızını azaltır.
- Bir sonraki isteği göndermeden önce her yanıtı bekleyen bir istemci, kayıt defterine gidiş dönüş süresiyle sınırlıdır. Kayıt defterinden en iyi şekilde yararlanmak için istekleri eşzamanlı olarak gönderin ve bağlantıları yeniden kullanabilirsiniz.
İş yükünüzün sürekli yüksek aktarım hızına ihtiyacı varsa üretime geçmeden önce bunu bir kayıt defterinde test edin. Daha fazla aktarım hızına ihtiyacınız varsa Azure desteği başvurun.
Latency
- Varsayılan olarak, yazma isteği kayıt defteri yazma işlemini kabul eder etmez ve kayıt defteri yazma işlemini kısa bir süre sonra işler. Örneğin alındı bilgisini almak için bir yazma işlemine güvenmeden önce durumunun olup
Committedolmadığını denetleyin. İstemci kitaplıkları sizin için işlemeyi bekleyebilir. - Kayıt defteri verileri yüklerken, işlem kimliğine göre giriş alma, alındı bilgisi alma ve aralık sorguları önce döndürülebilir
Loading. Sonucu döndürene kadar isteği bir dakika içinde yineleyin. - Gecikme süresi de mesafeye ve yüke bağlıdır. Her yeni bağlantının kayıt defteriyle bir TLS el sıkışması gerekir, bu nedenle bağlantıları yeniden kullanabilir ve müşterilerinizi kayıt defterinin bölgesine yakın bir şekilde çalıştırabilirsiniz. Kayıt defteri üzerindeki yük dayanabileceğine yaklaştıkça gecikme süresinin artmasını bekleyin.