Práticas recomendadas e limitações

Considere estas diretrizes ao usar BatchJobService.

Melhorar a capacidade de processamento

• É melhor ter menos jobs maiores do que muitos jobs menores.

• Ordene as operações enviadas por upload por tipo de operação. Por exemplo, se o trabalho contiver operações para adicionar campanhas, grupos de anúncios e critérios de grupo de anúncios, ordene as operações no upload para que todas as operações de campanha sejam primeiro, seguidas por todas as operações de grupo de anúncios e, por fim, todas as operações de critério de grupo de anúncios.

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

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 grupo de listagem em um AssetGroup e um AdGroup, consecutivamente em um trabalho em lote, a API Google Ads poderá dividir essas operações em diferentes sub-lotes. Essa separação pode fazer com que toda a modificação falhe ou deixe 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. O AdGroupCriterionOperation gerencia grupos de produtos em um AdGroup, o que é comum em campanhas padrão do Shopping. Ambos são usados para definir a segmentação por produto. Se você fizer mudanças que afetam a hierarquia de segmentação de produtos nos dois contextos, agrupe essas operações consecutivamente no seu trabalho 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 grupo de fichas consecutivamente ao seu job em lote. Essa ordenação ajuda a agrupá-los em subbatches atômicos pela lógica de divisão em lotes 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 operarem nos mesmos objetos ao mesmo tempo, mantendo tamanhos grandes de jobs. Muitos jobs não concluídos, que têm o status RUNNING, tentam mudar o mesmo conjunto de objetos, o que pode levar a condições semelhantes a deadlock, resultando em lentidão grave e até mesmo falhas de jobs.

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

Recuperar resultados de maneira ideal

• Não consulte o status do trabalho com muita frequência para não correr o risco de atingir erros de limitação de taxa.

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

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

Outras orientações de uso

• É possível definir um limite máximo para a duração de um job em lote antes de ser cancelado. Ao criar um job em lote, defina o campo metadata.execution_limit_seconds como o limite de tempo preferido, em segundos. Não há um 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. Para resolver esse erro, reduza o número de operações e tente novamente o AddBatchJobOperationsRequest.

Limitações

• Cada BatchJob aceita até um milhão de operações.

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

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

• Na 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 campo page_size em ListBatchJobResultsRequest:

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

• Cada AddBatchJobOperationsRequest tem um tamanho máximo de 10.484.504 bytes. Se você exceder esse limite, vai 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 = 10_484_504;
  
  ... (code to get the request object)
  
  int sizeInBytes = request.getSerializedSize();
  

  Python

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

  Ruby

  
  require 'google/ads/google_ads'
  
  MAX_REQUEST_BYTES = 10484504
  
  ... (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 = 10484504;
  
  ... (code to get the request object)
  
  $size_in_bytes = $campaign->byteSize() . PHP_EOL;
  

  .NET

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

  Perl

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