Práticas recomendadas e limitações

Considere estas diretrizes ao usar BatchJobService.

Melhorar a capacidade de processamento

• É preferível ter menos jobs maiores do que muitos jobs menores.

• Ordene as operações enviadas por tipo. Por exemplo, se o job contém operações para adicionar campanhas, grupos de anúncios e critérios de grupos de anúncios, ordene as operações no upload para que todas as operações de campanha venham primeiro, seguidas por todas as operações de grupos de anúncios e, por fim, todas as operações de critérios de grupos de anúncios.

• Em operações do mesmo tipo, pode melhorar o desempenho agrupá-las por recurso pai. Por exemplo, se você tiver uma série de objetos AdGroupCriterionOperation, pode ser mais eficiente agrupar as operações por grupo de anúncios, em vez de misturar operações que afetam critérios de grupos de anúncios em grupos de anúncios diferentes.

Atomicidade na divisão em lote

A API Google Ads pode dividir as operações em um job em lote enviado em sub-lotes menores para processamento. Se você não agrupar operações relacionadas, como modificações de grupos de produtos anunciados em um AssetGroup e um AdGroup, consecutivamente em um job em lote, a API Google Ads poderá dividir essas operações em sub-lotes diferentes. Essa separação pode levar à falha de toda a modificação ou deixar a conta em um estado inconsistente.

Agrupamento lógico

AssetGroupListingGroupFilterOperation gerencia grupos de produtos anunciados em um AssetGroup, o que é comum em campanhas Performance Max. AdGroupCriterionOperation gerencia grupos de produtos anunciados em um AdGroup, o que é comum em campanhas padrão do Shopping. Ambos são usados para definir a segmentação de produtos. Se você fizer mudanças que afetam a hierarquia de segmentação de produtos em ambos os contextos, agrupe essas operações consecutivamente no job em lote para garantir que elas sejam aplicadas juntas.

Consistência de dados

Para manter a consistência dos dados e evitar atualizações parciais, adicione operações relacionadas de grupos de produtos anunciados consecutivamente ao job em lote. Essa ordem ajuda a agrupá-las em sub-lotes atômicos pela lógica de divisão em lote da API, o que evita que sua conta fique em um estado inconsistente.

Evitar problemas de simultaneidade

• Ao enviar vários jobs simultâneos para a mesma conta, tente reduzir a probabilidade de jobs operando nos mesmos objetos ao mesmo tempo, mantendo tamanhos de jobs grandes. Muitos jobs não concluídos, que têm o status de RUNNING, tentam modificar o mesmo conjunto de objetos, o que pode levar a condições semelhantes a impasse, resultando em lentidão grave e até mesmo falhas de jobs.

• Não envie várias operações que modificam o mesmo objeto no mesmo job, porque o resultado pode ser imprevisível.

Recuperar resultados de maneira ideal

• Não consulte o status do job com muita frequência, ou você corre o risco de atingir erros de limite de taxa.

• Não recupere mais de 1.000 resultados por página. O servidor pode retornar menos do que isso devido à carga ou outros fatores.

• A ordem dos resultados será a mesma da ordem de upload.

Orientações adicionais de uso

• Você pode definir um limite máximo para a duração de um job em lote antes de ser cancelado. Ao criar um novo job em lote, defina o metadata.execution_limit_seconds campo para o limite de tempo preferido, em segundos. Não há limite de tempo padrão se metadata.execution_limit_seconds não estiver definido.

• Recomendamos adicionar no máximo 1.000 operações por AddBatchJobOperationsRequest e usar o sequence_token para fazer upload do restante das operações para o mesmo job. Dependendo do conteúdo das operações, muitas operações em um único AddBatchJobOperationsRequest podem causar um erro REQUEST_TOO_LARGE. Você pode resolver esse erro reduzindo o número de operações e tentando novamente o AddBatchJobOperationsRequest.

Limitações

• Cada BatchJob oferece suporte a até um milhão operações.

• Cada conta pode ter até 100 jobs ativos ou pendentes ao mesmo tempo.

• Os jobs pendentes com mais de 7 dias são removidos automaticamente.

• A partir da v22, cada solicitação AddBatchJobOperations tem um limite de 10.000 operações de mutação por solicitação.

• A partir da v22, para o page_size campo em ListBatchJobResultsRequest:

  • Se page_size não estiver definido ou for 0, ele será definido como o máximo de 1.000.
  • Se page_size exceder 1.000 ou for menor que 0, a API retornará um INVALID_PAGE_SIZE erro.

• A partir da v23, cada AddBatchJobOperationsRequest tem um tamanho máximo de 41.937.920 bytes. Se você exceder esse limite, receberá um INTERNAL_ERROR. Você pode determinar o tamanho da solicitação antes de enviar e tomar as medidas adequadas se ela for muito grande.

  Java

  
  static final int MAX_REQUEST_BYTES = 41_937_920;
  
  ... (code to get the request object)
  
  int sizeInBytes = request.getSerializedSize();
  

  Python

  
  from google.ads.googleads.client import GoogleAdsClient
  
  MAX_REQUEST_BYTES = 41937920
  
  ... (code to get the request object)
  
  size_in_bytes = request._pb.ByteSize()
  

  Ruby

  
  require 'google/ads/google_ads'
  
  MAX_REQUEST_BYTES = 41937920
  
  ... (code to get the request object)
  
  size_in_bytes = request.to_proto.bytesize
  

  PHP

  
  use Google\Ads\GoogleAds\V16\Resources\Campaign;
  
  const MAX_REQUEST_BYTES = 41937920;
  
  ... (code to get the request object)
  
  $size_in_bytes = $campaign->byteSize() . PHP_EOL;
  

  .NET

  
  using Google.Protobuf;
  const int MAX_REQUEST_BYTES = 41937920;
  
  ... (code to get the request object)
  
  int sizeInBytes = request.ToByteArray().Length;
  

  Perl

  
  use Devel::Size qw(total_size);
  use constant MAX_REQUEST_BYTES => 41937920;
  
  ... (code to get the request object)
  
  my $size_in_bytes = total_size($request);
  

Tamanho de operação de mutação única

Embora a solicitação geral possa ser maior, o tamanho de uma única operação de mutação no lote é limitado a 10.484.488 bytes (aproximadamente 10,48 MB).