DocumentazioneExperience Cloud KCS

AEM as a Cloud Service: strategia e limiti consigliati per il caricamento di risorse in blocco a livello di programmazione (circa 50.000 risorse)

Ultimo aggiornamento: 31 luglio 2026

Questo articolo fornisce indicazioni sulle best practice, i limiti consigliati e la configurazione per il caricamento di risorse in massa a livello di programmazione in AEM as a Cloud Service utilizzando il caricamento binario diretto.

Descrizione description

Ambiente

Adobe Experience Manager as a Cloud Service (AEMaaCS) (tutte le versioni)

Problema/Sintomi

È necessario acquisire circa 50.000 risorse in AEM as a Cloud Service DAM da un sistema esterno utilizzando l’approccio di caricamento binario diretto con la libreria @adobe/aem-upload Node.js.

Per evitare di sovraccaricare il servizio Asset Compute o di attivare la limitazione, è necessario ottenere una conferma della strategia consigliata, della velocità effettiva supportata, delle dimensioni del batch, della concorrenza e di tutti i limiti ufficiali. Non è stato ancora segnalato alcun messaggio di errore, ma desideri convalidare l’approccio prima dell’acquisizione in produzione.

  • Volume di caricamento in blocco: 50.000 risorse
  • Approccio: caricamento binario diretto tramite URL predefiniti (@adobe/aem-upload)
  • Pattern batch: caricamento batch con logica per nuovi tentativi
  • Dimensione batch: la documentazione suggerisce 10-50 in produzione
  • Concorrenza: metodo withMaxConcurrent() disponibile
  • Autenticazione: credenziali del servizio (OAuth S2S / JWT)

Risoluzione resolution

Per risolvere il problema, segui i passaggi seguenti:

  1. Usa caricamento binario diretto

  2. Configura dimensioni batch e concorrenza

    • Utilizza il pattern Caricamento batch come descritto nella documentazione.

    • Configurazione iniziale consigliata:

      • batchSize: 20-50 file per batch
      • maxConcurrent: 5-8 caricamenti simultanei per processo client

    • Regolare questi valori in base ai risultati pilota e al comportamento del sistema osservato.

  3. Monitoraggio velocità effettiva ed elaborazione

    • Non esiste un limite rigido alle richieste al secondo o alle risorse all’ora per l’API di caricamento stessa.
    • Il throughput effettivo è regolato dalla larghezza di banda di rete e dalla concorrenza client.
    • Elaborazione post-caricamento (miniature, metadati, Dynamic Media, ecc.) è gestito dai microservizi Asset Compute. Le velocità di elaborazione tipiche sono di 5.000-9.000 risorse all’ora.
    • Per 50.000 risorse, l’elaborazione dovrebbe essere completata entro poche o diverse ore in condizioni standard.

  4. Programma pilota e monitoraggio

    • Esegui un programma pilota con 1.000-2.000 risorse per convalidare la configurazione e monitorare errori quali timeout, HTTP 413 (Payload troppo grande) o HTTP 429 (Troppe richieste).
    • Monitora i tempi di elaborazione e *Processing…*banner in AEM.
    • Regola le dimensioni del batch e la concorrenza secondo necessità per ottimizzare la velocità effettiva senza attivare la limitazione.

  5. Autenticazione e autorizzazioni

    • Utilizza le credenziali del servizio (OAuth S2S / JWT) con un account che dispone delle autorizzazioni di caricamento necessarie.

  6. Pianifica Caricamenti In Modo Appropriato

    • Per questo volume non è richiesto alcun aumento di livello dell’ambiente.
    • Valuta l’esecuzione di caricamenti durante le ore di minore utilizzo per massimizzare la velocità effettiva di elaborazione.

Causa

L’approccio al caricamento binario diretto è progettato per l’acquisizione di volumi elevati e sfrutta l’archiviazione cloud e i microservizi per la scalabilità. Il throughput è limitato principalmente dalla capacità di elaborazione post-caricamento, non dall’API di caricamento stessa.

recommendation-more-help
experience-cloud-kcs-help-kbarticles