Prácticas recomendadas y limitaciones

Ten en cuenta estos lineamientos cuando uses BatchJobService.

Mejora la capacidad de procesamiento

  • Se prefieren menos trabajos más grandes que muchos trabajos más pequeños.

  • Ordena las operaciones subidas por tipo de operación (excepto las operaciones interdependientes que deben agruparse de forma consecutiva en sublotes atómicos). Por ejemplo, si tu trabajo contiene operaciones para agregar campañas estándar, grupos de anuncios y criterios del grupo de anuncios, ordena las operaciones en tu carga de modo que todas las operaciones de la campaña se realicen primero, seguidas de todas las operaciones del grupo de anuncios y, por último, todas las operaciones del criterio del grupo de anuncios.

  • En las operaciones del mismo tipo, puede mejorar el rendimiento agruparlas por recurso principal. Por ejemplo, si tienes una serie de objetos AdGroupCriterionOperation, es más eficiente agrupar las operaciones por grupo de anuncios que intercalar operaciones que afectan los criterios de grupos de anuncios en diferentes grupos de anuncios.

Atomicidad en la división por lotes

La API de Google Ads divide las operaciones de un trabajo por lotes enviado en sub-lotes más pequeños para su procesamiento. Si bien los sublotes estándar se ejecutan con la falla parcial habilitada, los sublotes de ciertas operaciones interdependientes se procesan de forma atómica como una sola transacción:

Para los lotes secundarios de creación de AssetGroup y de campañas de máximo rendimiento Campaign (hasta 1,000 operaciones en total por lote secundario; las operaciones secundarias de create que superen las 999 se incluirán en el siguiente lote secundario no atómico):

  • La operación principal create (resource_name en AssetGroup o Campaign) y sus operaciones secundarias consecutivas create (asset_group en AssetGroupAsset o campaign en CampaignAsset) deben especificar el mismo ID temporal negativo.
  • Coloca las operaciones de AssetOperation (create) de requisitos previos para los recursos Asset nuevos antes de las operaciones de AssetGroupOperation o CampaignOperation (create) principales, nunca entre la operación de create principal y sus operaciones de create de vínculo secundario (lo que cerraría de inmediato el sublote atómico y separaría la creación del recurso principal de sus recursos vinculados).

Cuando falla un sublote atómico, el objeto BatchJobResult.status de la operación infractora contiene el error de validación subyacente, mientras que las operaciones restantes de ese sublote se revierten con el error de transacción correspondiente para ese sublote. Inspecciona las entradas BatchJobResult adyacentes que comparten el mismo ID de AdGroup, AssetGroup o Campaign para identificar el error de causa raíz.

Si las operaciones relacionadas en cualquiera de estos grupos no se agregan de forma consecutiva, la API de Google Ads las divide en sublotes separados, lo que provoca que la modificación no cumpla con los requisitos mínimos de recursos o que los árboles de grupos de fichas queden incompletos. Consulta Cómo usar filtros de grupos de fichas en trabajos por lotes y Procesamiento por lotes de las campañas de máximo rendimiento para obtener más detalles.

Agrupación lógica

Cuando modifiques una jerarquía de segmentación por producto (AssetGroupListingGroupFilterOperation en las campañas de máximo rendimiento o AdGroupCriterionOperation en las campañas de Compras) o crees un AssetGroup o una campaña de máximo rendimiento Campaign nuevos, agrupa todas las operaciones que segmenten el mismo recurso principal (AssetGroup, AdGroup o Campaign) de forma consecutiva. Esto reduce la contención de bloqueo del backend y mantiene juntos los árboles interdependientes.

Coherencia de los datos

Dado que los árboles de filtros de grupos de fichas y los requisitos de recursos de las campañas de máximo rendimiento se validan al final de cada transacción atómica de sub-lote, evita dividir las actualizaciones del mismo recurso principal en rangos discontinuos en un trabajo o en trabajos simultáneos.

Evita problemas de simultaneidad

  • Cuando envíes varios trabajos simultáneos para la misma cuenta, reduce la probabilidad de que los trabajos operen en los mismos objetos al mismo tiempo y mantén tamaños de trabajo grandes. Muchos trabajos sin terminar con el estado RUNNING que intentan mutar el mismo conjunto de objetos pueden generar condiciones similares a un bloqueo, lo que provoca una ralentización grave e incluso fallas en el trabajo.

  • No envíes varias operaciones que modifiquen el mismo objeto en el mismo trabajo, ya que el resultado puede ser impredecible.

Recupera resultados de forma óptima

  • No sondee el estado del trabajo con demasiada frecuencia, ya que corre el riesgo de alcanzar errores de límite de frecuencia.

  • Deja page_size sin configurar (o configúralo en el máximo de 1000) cuando llames a ListBatchJobResults para minimizar los viajes de ida y vuelta de paginación, y solo establece response_content_type en MUTABLE_RESOURCE si tu aplicación inspecciona los campos de recursos devueltos más allá de resource_name.

  • El orden de los resultados es el mismo que el orden de carga.

Orientación adicional sobre el uso

  • Puedes establecer un límite superior para el tiempo que se permite que se ejecute un trabajo por lotes antes de que se cancele. Cuando crees un trabajo por lotes nuevo, configura el campo metadata.execution_limit_seconds en el límite de tiempo que prefieras, en segundos. No hay un límite de tiempo predeterminado si no se establece metadata.execution_limit_seconds.

  • Si bien el límite del protocolo es de 10,000 operaciones por solicitud, recomendamos agregar no más de 1,000 operaciones por AddBatchJobOperationsRequest y usar sequence_token para subir el resto de las operaciones al mismo trabajo. Según el tamaño de las operaciones, enviar demasiadas operaciones en un solo AddBatchJobOperationsRequest puede causar un error BatchJobError.REQUEST_TOO_LARGE. Para controlar este error, reduce la cantidad de operaciones y vuelve a intentar la llamada a AddBatchJobOperationsRequest.

Limitaciones

  • Cada BatchJob admite hasta un millón de operaciones. Si se supera este límite cuando se llama a AddBatchJobOperations, se muestra un error ResourceCountLimitExceededError.RESOURCE_LIMIT (con ResourceLimitType.BATCH_JOB_OPERATIONS_PER_JOB en ErrorDetails.resource_count_details).

  • Cada cuenta puede tener hasta 100 trabajos activos o pendientes al mismo tiempo. Si se supera este límite cuando se crea un trabajo por lotes con MutateBatchJob, se muestra un error ResourceCountLimitExceededError.RESOURCE_LIMIT (con ResourceLimitType.BATCH_JOBS_PER_CUSTOMER en ErrorDetails.resource_count_details).

  • Los trabajos pendientes con más de 7 días de antigüedad se quitan automáticamente.

  • Cada AddBatchJobOperationsRequest tiene un límite fijo de 10,000 operaciones de mutación por solicitud. Si se superan las 10,000 operaciones en una sola solicitud, se devuelve un error BatchJobError.REQUEST_TOO_LARGE.

  • Para el campo page_size en ListBatchJobResultsRequest, haz lo siguiente:

  • Cada AddBatchJobOperationsRequest tiene un tamaño máximo de 41,937,920 bytes. Si superas este límite, recibirás un error BatchJobError.REQUEST_TOO_LARGE (o un error INTERNAL_ERROR si se rechaza en la capa de transporte). Puedes determinar el tamaño serializado de la solicitud antes de enviarla y tomar las medidas adecuadas si es demasiado grande:

    Java

    
static final int MAX_REQUEST_BYTES = 41_937_920;

// ... (code to get the AddBatchJobOperationsRequest object)

int sizeInBytes = request.getSerializedSize();

    C#

    
const int MAX_REQUEST_BYTES = 41_937_920;

// ... (code to get the AddBatchJobOperationsRequest object)

int sizeInBytes = request.CalculateSize();

    PHP

    
const MAX_REQUEST_BYTES = 41937920;

// ... (code to get the AddBatchJobOperationsRequest object)

$size_in_bytes = $request->byteSize();

    Python

    
MAX_REQUEST_BYTES = 41_937_920

# ... (code to get the AddBatchJobOperationsRequest object)

size_in_bytes = type(request).pb(request).ByteSize()

    Ruby

    
MAX_REQUEST_BYTES = 41_937_920

# ... (code to get the AddBatchJobOperationsRequest object)

size_in_bytes = request.to_proto.bytesize

    Perl

    
use JSON::XS;
use constant MAX_REQUEST_BYTES => 41937920;

# ... (code to get the AddBatchJobOperationsRequest object)

# The Perl client library uses REST/JSON; UTF-8 JSON byte length provides a
# conservative upper-bound estimate of the serialized request size.
my $json_encoder = JSON::XS->new->utf8->convert_blessed;
my $size_in_bytes = length($json_encoder->encode($request));

Tamaño de una sola operación de mutación

Si bien la solicitud general puede tener hasta 41,937,920 bytes, el tamaño serializado de un solo MutateOperation dentro del lote se limita a 10,484,504 bytes (10 MiB menos 1,256 bytes). Si se supera este límite, se muestra un error BatchJobError.REQUEST_TOO_LARGE. Ten en cuenta que,si bien la documentación de referencia de BatchJobError.REQUEST_TOO_LARGE cita el umbral de 10,484, 504 bytes,AddBatchJobOperations devuelve este mismo código de error cuando se supera cualquiera de los tres umbrales de solicitud (41,937,920 bytes totales de solicitud,10,484, 504 bytes de operación única o 10,000 operaciones por llamada), y el campo message del error especifica qué límite se incumplió.

Anterior
Filtros de grupos de fichas