Azure confidential ledger limits

O livro de registos confidencial do Azure limita o número de livros-razão numa subscrição e os dados e código que um registo armazena, para manter o desempenho e a disponibilidade de cada registo previsíveis. Este artigo descreve estes limites, como o livro razão responde quando um pedido os ultrapassa e que desempenho esperar de um livro maior.

Note

Os limites deste artigo são defaults. Em certos casos, um livro razão individual pode ter limites diferentes, por exemplo, um livro razão criado antes de um limite ser introduzido. Para solicitar limites mais elevados ou discutir limitações, contacte o suporte do suporte do Azure.

Limites da subscrição

O seguinte limite aplica-se a cada subscrição do Azure.

Limit Value
Registos por subscrição 2

Limites de dados do livro-razão

Os seguintes limites aplicam-se a todos os livros-razão por defeito.

Limit Valor predefinido Código de erro
Cobranças por livro-razão 5.000 CollectionCapacityExceeded
Comprimento do ID da coleção 256 bytes CollectionIdTooLong
Tamanho do conteúdo de uma entrada do livro razão 8 KiB (8.192 bytes) EntrySizeCapacityExceeded
Etiquetas por livro-razão (apenas livros-razão públicos) 10,000 TagCapacityExceeded
  • Cobranças por livro-caixa: A coleção padrão não é contabilizada. Quando um livro de registos atinge o limite, as escritas que criariam uma nova coleção são rejeitadas. As escritas para coleções existentes continuam a ter sucesso.
  • Comprimento do ID da Coleção: O comprimento é medido em bytes do ID codificado em UTF-8, após a decodificação da URL. O limite aplica-se apenas quando um escrita cria uma nova coleção, por isso pode continuar a escrever e a ler coleções criadas antes deste limite ser introduzido.
  • Tamanho do conteúdo de uma entrada do livro de registo: O tamanho é medido em bytes do valor codificado contents em UTF-8, após a decodificação JSON. São aceites conteúdos de exatamente 8.192 bytes. O limite aplica-se a escritas tanto em coleções novas como existentes. O ID da coleção, as etiquetas e outros campos do pedido não contam para este limite. Todo o pedido está também sujeito ao tamanho máximo do corpo pedido pelo livro de contas.
  • Etiquetas por livro-livro: Uma etiqueta conta uma vez por cada coleção que a utiliza. Por exemplo, a etiqueta chocolate usada em duas coleções conta como duas etiquetas. Quando um livro de registos atinge o limite, as escritas que adicionariam uma nova etiqueta a uma coleção são rejeitadas. Escritas sem etiquetas, ou com etiquetas que a coleção já utiliza, continuam a ter sucesso.

Uma escrita que ultrapasse um limite é rejeitada com o código de estado HTTP 400 (Pedido Mau), e nada no pedido é escrito no livro-registo. A resposta contém o código de erro e uma mensagem que inclui o limite aplicável ao livro-razão (ledger). Por exemplo:

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

Limites de etiquetas por escrita

As etiquetas são suportadas apenas em registos públicos. Os seguintes limites aplicam-se a todos os livros públicos.

Limit Value
Etiquetas por escrita 5
Comprimento da etiqueta 63 personagens

As etiquetas não podem ser vazias e podem conter apenas os caracteres A–Z, a–z, 0–9, -, _, ., e ~. Uma escrita que ultrapasse estes limites ou contenha uma etiqueta inválida é rejeitada com o código de estado HTTP 400 e o código de NotAllowed erro.

Limites de funções definidos pelo utilizador

Os seguintes limites aplicam-se às funções definidas pelo utilizador (UDFs) em cada livro de registos. Pedidos que excedam esses requisitos são rejeitados com o código de estado HTTP 400.

Limit Value Código de erro
UDFs por livro-razão 100 UserDefinedFunctionCapacityExceeded
Comprimento do ID UDF 256 bytes InvalidFunctionId
Tamanho do código UDF 64 KiB (65.536 bytes) InvalidInput
Pré-ganchos por escrita 5 InvalidInput
Ganchos pós-chave por escrita 5 InvalidInput

Os limites de contagem de UDF e de comprimento do ID aplicam-se apenas quando se cria um UDF. Ainda podes atualizar um UDF existente se o seu código se encaixar dentro de 64 KiB.

Para as opções de runtime que se aplicam quando um UDF é executado, veja Running UDFs. Para mais informações sobre pré-ganchos e pós-ganchos, veja Ganchos de Transação.

Opções de runtime de endpoint definidas pelo utilizador

Os valores definidos com PATCH /app/userDefinedEndpoints/runtimeOptions devem estar dentro dos seguintes intervalos. Caso contrário, o pedido é rejeitado com o código de estado HTTP 400 e o código de InvalidInput erro. Apenas as opções cujo valor o pedido altera são verificadas.

Opção de tempo de execução Valores permitidos
max_heap_bytes Até 209.715.200 (200 MiB)
max_stack_bytes 1 a 10.485.760 (10 MiB)
max_execution_time_ms Até 10.000 (10 segundos)
max_cached_interpreters 1 a 20

Performance

O desempenho de um livro de registos depende da sua carga de trabalho, como o tamanho das suas entradas, quantos pedidos envia simultaneamente e a combinação de leituras e escritas. As orientações seguintes dão uma ideia geral do que esperar. Não é garantido.

Throughput

  • Um livro de registos pode suportar centenas de escritas por segundo. Entradas mais pequenas e pedidos mais simultâneos aumentam a taxa. Escritas que executam funções definidas pelo utilizador demoram mais, dependendo do código das funções.
  • Ler a entrada mais recente de uma coleção consome menos recursos do que uma escrita, pelo que um livro de registos pode normalmente servir mais destes pedidos. Obter uma entrada por ID de transação, obter um recibo e consultas por intervalo consome mais recursos do que ler a última entrada, porque o livro razão carrega primeiro os dados do armazenamento. Uma elevada taxa destes pedidos reduz o débito deixado para escritas.
  • Um cliente que espera por cada resposta antes de enviar o próximo pedido é limitado pelo tempo de ida e volta ao livro-razão (ledger). Para tirar o máximo proveito de um livro de registos, envie pedidos em simultâneo e reutilize as ligações.

Se a tua carga de trabalho precisar de um alto rendimento sustentado, testa-a num registo antes de entrares em produção. Se precisar de mais rendimento, contacte o suporte do Azure.

Latency

  • Por defeito, um pedido de escrita retorna assim que o livro-razão aceita a escrita, e o livro-razão confirma a escrita pouco depois. Antes de confiar numa escrita, por exemplo, para obter o recibo, verifique se o seu estado é Committed. As bibliotecas clientes podem esperar pelo commit por ti.
  • Obter uma entrada por ID de transação, obter um recibo e consultas por intervalo pode ser retornado Loading primeiro, enquanto o livro de contas carrega os dados. Repita o pedido dentro de um minuto até devolver o resultado.
  • A latência também depende da distância e da carga. Cada nova ligação precisa de um handshake TLS com o livro de registo, por isso reutilize as ligações e coloque os seus clientes perto da região do livro de registos. Espere que a latência aumente à medida que a carga no livro razão se aproxima do que pode suportar.

Conteúdo relacionado

  • Última atualização a