Best Practices und Einschränkungen

Beachten Sie die folgenden Richtlinien, wenn Sie BatchJobService verwenden.

Durchsatz verbessern

  • Weniger größere Jobs sind vielen kleineren Jobs vorzuziehen.

  • Ordnen Sie hochgeladene Vorgänge nach Vorgangstyp (mit Ausnahme von voneinander abhängigen Vorgängen, die in atomaren Sub-Batches aufeinanderfolgend gruppiert werden müssen). Wenn Ihr Job beispielsweise Vorgänge zum Hinzufügen von Standardkampagnen, Anzeigengruppen und Anzeigengruppenkriterien enthält, sollten Sie die Vorgänge in Ihrem Upload so anordnen, dass zuerst alle Kampagnenvorgänge, dann alle Anzeigengruppenvorgänge und schließlich alle Anzeigengruppenkriteriumsvorgänge ausgeführt werden.

  • Bei Vorgängen desselben Typs kann es die Leistung verbessern, wenn Sie sie nach übergeordneter Ressource gruppieren. Wenn Sie beispielsweise eine Reihe von AdGroupCriterionOperation-Objekten haben, ist es effizienter, Vorgänge nach Anzeigengruppe zu gruppieren, anstatt Vorgänge zu mischen, die sich auf Anzeigengruppenkriterien in verschiedenen Anzeigengruppen auswirken.

Atomarität beim Aufteilen von Batches

In der Google Ads API werden die Vorgänge in einem eingereichten Batchjob zur Verarbeitung in kleinere Unter-Batches aufgeteilt. Standard-Unterbatches werden mit aktivierter Option für Teilausfälle ausgeführt. Unterbatches für bestimmte voneinander abhängige Vorgänge werden jedoch atomar als einzelne Transaktion verarbeitet:

Für Unterbatches zum Erstellen von AssetGroup- und Performance Max-Kampagnen Campaign (bis zu 1.000 Vorgänge insgesamt pro Unterbatch; alle untergeordneten create-Vorgänge über 999 hinaus werden in den nächsten nicht atomaren Unterbatch übertragen):

  • Für den übergeordneten create-Vorgang (resource_name für AssetGroup oder Campaign) und die nachfolgenden untergeordneten create-Vorgänge (asset_group für AssetGroupAsset oder campaign für CampaignAsset) muss dieselbe negative temporäre ID angegeben werden.
  • Platzieren Sie alle erforderlichen AssetOperation-Vorgänge (create) für neue Asset-Ressourcen vor dem übergeordneten AssetGroupOperation- oder CampaignOperation-Vorgang (create), niemals zwischen dem übergeordneten create-Vorgang und den zugehörigen untergeordneten Linkvorgängen (create), da dadurch der atomare Unter-Batch sofort geschlossen und die Erstellung der übergeordneten Ressource von den verknüpften Assets getrennt würde.

Wenn ein atomarer Unter-Batch fehlschlägt, enthält das BatchJobResult.status des fehlerhaften Vorgangs den zugrunde liegenden Validierungsfehler. Die verbleibenden Vorgänge in diesem Unter-Batch werden mit dem entsprechenden Transaktionsfehler für diesen Unter-Batch zurückgesetzt. Sehen Sie sich die benachbarten BatchJobResult-Einträge mit derselben AdGroup-, AssetGroup- oder Campaign-ID an, um den Fehler zu finden, der die Ursache ist.

Wenn zugehörige Vorgänge in einer dieser Gruppen nicht nacheinander hinzugefügt werden, werden sie in der Google Ads API in separate Unter-Batches aufgeteilt. Dadurch kann es passieren, dass die Mindestanforderungen für Assets nicht erfüllt werden oder die Bäume der Eintragsgruppen unvollständig sind. Weitere Informationen finden Sie unter Eintragsgruppenfilter in Batchjobs verwenden und Batchverarbeitung von Performance Max-Kampagnen.

Logische Gruppierung

Wenn Sie eine Hierarchie für die Produktausrichtung ändern (AssetGroupListingGroupFilterOperation in Performance Max-Kampagnen oder AdGroupCriterionOperation in Shopping-Kampagnen) oder eine neue AssetGroup oder Performance Max-Campaign erstellen, gruppieren Sie alle Vorgänge, die auf dieselbe übergeordnete Ressource (AssetGroup, AdGroup oder Campaign) ausgerichtet sind, nacheinander. Dadurch werden Konflikte bei Backend-Sperren reduziert und voneinander abhängige Bäume bleiben zusammen.

Datenkonsistenz

Da Eintragsgruppen-Filterbäume und Anforderungen an Assets für Performance Max-Kampagnen am Ende jeder atomaren Sub-Batch-Transaktion validiert werden, sollten Sie Aktualisierungen derselben übergeordneten Ressource nicht auf diskontinuierliche Bereiche in einem Job oder auf gleichzeitige Jobs aufteilen.

Probleme mit der Nebenläufigkeit vermeiden

  • Wenn Sie mehrere gleichzeitige Jobs für dasselbe Konto einreichen, können Sie die Wahrscheinlichkeit verringern, dass Jobs gleichzeitig auf dieselben Objekte zugreifen, ohne die Jobgröße zu verringern. Viele unvollständige Jobs mit dem Status RUNNING, die versuchen, dieselben Objekte zu ändern, können zu Deadlock-ähnlichen Bedingungen führen, die zu erheblichen Verlangsamungen und sogar zu Jobfehlern führen.

  • Reichen Sie nicht mehrere Vorgänge ein, die dasselbe Objekt im selben Job ändern, da das Ergebnis unvorhersehbar sein kann.

Ergebnisse optimal abrufen

  • Rufen Sie den Jobstatus nicht zu häufig ab, da sonst Ratenbegrenzungen erreicht werden können.

  • Lassen Sie page_size beim Aufrufen von ListBatchJobResults nicht festgelegt (oder legen Sie es auf den Maximalwert von 1000 fest), um die Anzahl der Roundtrips für die Paginierung zu minimieren. Legen Sie response_content_type nur auf MUTABLE_RESOURCE fest, wenn Ihre Anwendung die zurückgegebenen Ressourcenfelder über resource_name hinaus prüft.

  • Die Reihenfolge der Ergebnisse entspricht der Reihenfolge der Uploads.

Zusätzliche Hinweise zur Verwendung

  • Sie können eine Obergrenze für die Ausführungsdauer eines Batchjobs festlegen, bevor er abgebrochen wird. Legen Sie beim Erstellen eines neuen Batchjobs das Feld metadata.execution_limit_seconds auf das gewünschte Zeitlimit in Sekunden fest. Wenn metadata.execution_limit_seconds nicht festgelegt ist, gibt es kein Standardzeitlimit.

  • Das Protokolllimit liegt bei 10.000 Vorgängen pro Anfrage. Wir empfehlen jedoch, nicht mehr als 1.000 Vorgänge pro AddBatchJobOperationsRequest hinzuzufügen und die restlichen Vorgänge mit sequence_token in denselben Job hochzuladen. Je nach Größe der Vorgänge kann das Senden zu vieler Vorgänge in einem einzelnen AddBatchJobOperationsRequest einen BatchJobError.REQUEST_TOO_LARGE-Fehler verursachen. Sie können diesen Fehler beheben, indem Sie die Anzahl der Vorgänge reduzieren und die AddBatchJobOperationsRequest noch einmal versuchen.

Beschränkungen

  • Jede BatchJob unterstützt bis zu eine Million Vorgänge. Wenn Sie dieses Limit beim Aufrufen von AddBatchJobOperations überschreiten, wird ein ResourceCountLimitExceededError.RESOURCE_LIMIT-Fehler (mit ResourceLimitType.BATCH_JOB_OPERATIONS_PER_JOB in ErrorDetails.resource_count_details) zurückgegeben.

  • Jedes Konto kann bis zu 100 aktive oder ausstehende Jobs gleichzeitig haben. Wenn Sie dieses Limit beim Erstellen eines Batchjobs mit MutateBatchJob überschreiten, wird ein ResourceCountLimitExceededError.RESOURCE_LIMIT-Fehler zurückgegeben (mit ResourceLimitType.BATCH_JOBS_PER_CUSTOMER in ErrorDetails.resource_count_details).

  • Ausstehende Jobs, die älter als 7 Tage sind, werden automatisch entfernt.

  • Für jede AddBatchJobOperationsRequest gilt ein hartes Limit von 10.000 Mutationsvorgängen pro Anfrage. Wenn Sie in einer einzelnen Anfrage mehr als 10.000 Vorgänge ausführen,wird der Fehler BatchJobError.REQUEST_TOO_LARGE zurückgegeben.

  • Für das Feld page_size in ListBatchJobResultsRequest:

  • Jede AddBatchJobOperationsRequest darf maximal 41.937.920 Byte groß sein. Wenn Sie dieses Limit überschreiten, erhalten Sie den Fehler BatchJobError.REQUEST_TOO_LARGE (oder INTERNAL_ERROR, wenn die Anfrage auf der Transportschicht abgelehnt wird). Sie können die serialisierte Größe der Anfrage vor dem Senden ermitteln und entsprechende Maßnahmen ergreifen, wenn sie zu groß ist:

    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));

Größe eines einzelnen Änderungsvorgangs

Die Gesamtgröße der Anfrage darf bis zu 41.937.920 Byte betragen. Die serialisierte Größe eines einzelnen MutateOperation im Batch ist jedoch auf 10.484.504 Byte (10 MiB minus 1.256 Byte) begrenzt. Bei Überschreiten dieses Limits wird ein BatchJobError.REQUEST_TOO_LARGE-Fehler zurückgegeben. In der Referenzdokumentation für BatchJobError.REQUEST_TOO_LARGE wird zwar der Grenzwert von 10.484.504 Byte angegeben, AddBatchJobOperations gibt diesen Fehlercode jedoch zurück, wenn einer der drei Anfragengrenzwerte (41.937.920 Byte für die gesamte Anfrage, 10.484.504 Byte für einen einzelnen Vorgang oder 10.000 Vorgänge pro Aufruf) überschritten wird. Im Feld message des Fehlers wird angegeben, welches Limit überschritten wurde.

Zurück
Filter für Eintragsgruppen