AEM as a Cloud Service : stratégie et limites recommandées pour le chargement de ressources par programmation en bloc (environ 50 000 ressources)
Cet article fournit des conseils sur les bonnes pratiques, les limites recommandées et la configuration pour les chargements de ressources programmatiques en masse vers AEM as a Cloud Service à l’aide du chargement binaire direct.
Description description
Environnement
Adobe Experience Manager as a Cloud Service (AEMaaCS) (toutes les versions)
Problème/Symptômes
Vous devez ingérer environ 50 000 ressources dans la gestion des ressources numériques d’AEM as a Cloud Service à partir d’un système externe à l’aide de l’approche de chargement binaire direct avec la bibliothèque Node.js @adobe/aem-upload.
Vous devez obtenir une confirmation sur la stratégie recommandée, le débit pris en charge, la taille du lot, la simultanéité et toute limite officielle pour éviter de surcharger le service Asset Compute ou de déclencher le ralentissement. Aucun message d’erreur n’a encore été signalé, mais vous souhaitez valider l’approche avant l’ingestion en production.
- Volume de chargement en masse : 50 000 ressources
- Approche : chargement binaire direct via des URL prédéfinies (
@adobe/aem-upload) - Modèle de lot : chargement par lots avec logique de reprise
- Taille de lot : la documentation suggère 10 à 50 en production
- Simultanéité :
withMaxConcurrent()méthode disponible - Authentification : informations d’identification de service (OAuth S2S/JWT)
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème :
-
Utiliser le chargement binaire direct
- Suivez le tutoriel sur le chargement de ressources par programme et référence de l’API HTTP de chargement de ressources.
- La méthode de chargement binaire direct est recommandée pour une ingestion à grande échelle, car elle charge les fichiers directement dans l’espace de stockage cloud et réduit la charge sur la JVM AEM.
-
Configurer la taille du lot et la simultanéité
-
Utilisez le modèle Chargement par lots comme décrit dans la documentation.
-
Configuration de démarrage recommandée :
batchSize: 20 à 50 fichiers par lotmaxConcurrent: 5 à 8 chargements simultanés par processus client
-
Ajustez ces valeurs en fonction des résultats du pilote et du comportement observé du système.
-
-
Surveillance du débit et du traitement
- Il n’existe aucune limite stricte stricte en termes de requêtes par seconde ou de ressources par heure pour l’API de chargement elle-même.
- Le débit réel est régi par la bande passante du réseau et la simultanéité du client.
- Traitement après chargement (miniatures, métadonnées, Dynamic Media, etc.) est géré par les microservices Asset Compute. Les taux de traitement standard sont compris entre 5 000 et 9 000 ressources par heure.
- Pour 50 000 ressources, le traitement doit se terminer en quelques heures ou plusieurs heures dans des conditions standard.
-
Pilote et moniteur
- Exécutez un pilote avec 1 000 à 2 000 ressources pour valider la configuration et surveiller les erreurs telles que les délais d’expiration, HTTP 413 (Payload trop grande) ou HTTP 429 (Too many requests).
- Surveillez les temps de traitement et les bannières Traitement… dans AEM.
- Ajustez la taille du lot et la simultanéité selon les besoins pour optimiser le débit sans déclencher de ralentissement.
-
Authentification et autorisations
- Utilisez les informations d’identification de service (OAuth S2S/JWT) avec un compte disposant des autorisations de chargement requises.
-
Planifiez Les Chargements De Manière Appropriée
- Aucune mise à l’échelle d’environnement spéciale n’est requise pour ce volume.
- Envisagez d’exécuter des chargements pendant les heures creuses pour optimiser le débit de traitement.
Cause
L’approche du chargement binaire direct est conçue pour l’ingestion de volumes importants et utilise l’espace de stockage dans le cloud et les microservices pour offrir une évolutivité accrue. Le débit est principalement limité par la capacité de traitement après chargement, et non par l’API de chargement elle-même.