DocumentaciónKCS de Experience Cloud

AEM as a Cloud Service: estrategia recomendada y límites para la carga de recursos programáticos en lotes (aproximadamente 50 000 recursos)

Última actualización: 31 de julio de 2026

En este artículo se explica cuáles son las prácticas recomendadas, los límites recomendados y la configuración para las cargas de recursos programáticos en masa a AEM as a Cloud Service mediante la carga binaria directa.

Descripción description

Entorno

Adobe Experience Manager as a Cloud Service (AEMaaCS) (todas las versiones)

Problema/Síntomas

Debe ingerir aproximadamente 50 000 recursos en el DAM de AEM as a Cloud Service desde un sistema externo utilizando el método de carga binaria directa con la biblioteca @adobe/aem-upload Node.js.

Solicite confirmación sobre la estrategia recomendada, el rendimiento admitido, el tamaño del lote, la concurrencia y cualquier límite oficial para evitar sobrecargar el servicio de Asset Compute o activar la limitación. Aún no se ha informado de mensajes de error, pero desea validar el método antes de la ingesta de producción.

  • Volumen de carga masiva: 50 000 recursos
  • Método: carga binaria directa mediante direcciones URL prefirmadas (@adobe/aem-upload)
  • Patrón de lotes: carga por lotes con lógica de reintentos
  • Tamaño del lote: la documentación sugiere que hay entre 10 y 50 en producción
  • Simultaneidad: método withMaxConcurrent() disponible
  • Autenticación: credenciales de servicio (OAuth S2S/JWT)

Resolución resolution

Siga los pasos a continuación para resolver el problema:

  1. Usar carga binaria directa

  2. Configurar el tamaño y la simultaneidad del lote

    • Utilice el patrón Carga por lotes como se describe en la documentación.

    • Configuración de inicio recomendada:

      • batchSize: 20 a 50 archivos por lote
      • maxConcurrent: de 5 a 8 cargas simultáneas por proceso de cliente

    • Ajuste estos valores en función de los resultados del piloto y del comportamiento observado del sistema.

  3. Monitorizar rendimiento y procesamiento

    • No hay un límite estricto de solicitudes por segundo o recursos por hora para la propia API de carga.
    • El rendimiento real se rige por el ancho de banda de la red y la concurrencia del cliente.
    • Procesamiento posterior a la carga (miniaturas, metadatos, Dynamic Media, etc.) se administra mediante microservicios de Asset Compute. Las tasas de procesamiento habituales son de 5000 a 9000 recursos por hora.
    • Para 50 000 recursos, el procesamiento debería completarse en unas pocas o varias horas en condiciones estándar.

  4. Piloto y monitor

    • Ejecute un programa piloto con entre 1000 y 2000 recursos para validar la configuración y supervisar errores como tiempos de espera, HTTP 413 (Carga útil demasiado grande) o HTTP 429 (Demasiadas solicitudes).
    • Monitorice los tiempos de procesamiento y *Procesando…*banners en AEM.
    • Ajuste el tamaño del lote y la concurrencia según sea necesario para optimizar el rendimiento sin activar la limitación.

  5. Autenticación y permisos

    • Utilice credenciales de servicio (OAuth S2S/JWT) con una cuenta que tenga los permisos de carga necesarios.

  6. Programar cargas correctamente

    • No se requiere una ampliación de entorno especial para este volumen.
    • Considere la posibilidad de ejecutar cargas durante las horas de menor actividad para maximizar el rendimiento del procesamiento.

Causa

El método de carga binaria directa está diseñado para la ingesta de gran volumen y aprovecha el almacenamiento en la nube y los microservicios para la escalabilidad. El rendimiento está limitado principalmente por la capacidad de procesamiento posterior a la carga, no por la propia API de carga.

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