Meilleures pratiques d'AMP Engine

• AMP améliore considérablement les performances et l'efficacité par rapport au moteur d'origine.
• AMP est conçu pour fonctionner avec de plus grands volumes de données à une vitesse plus élevée et exécute généralement des workflows plus rapidement, avec une utilisation efficace des ressources de la machine.
• L'architecture du moteur d'origine permet un traitement à thread unique, où vos données sont traitées de façon séquentielle, enregistrement par enregistrement. En revanche, le nouveau concept AMP permet un traitement multi-threaded massif. Les enregistrements sont traités dans des paquets de 4 Mo, pour un temps d'exécution plus rapide et parallèle, ce qui peut affecter l'ordre des enregistrements de sortie.
• L'article AMPlifiez vos workflows présente certains avantages de performances offerts par l'utilisation d'AMP Engine :
  • Les outils les plus couramment utilisés sont plus performants sur AMP. 
  • Les avantages tirés d'AMP augmentent généralement au fur et à mesure que la taille des données augmente.
  • La vitesse varie en fonction de la taille des données, du matériel sous-jacent et de la construction de workflows.

Pour plus d'informations, reportez-vous aux liens vers la documentation au bas de ce document. 

Designer a activé AMP par défaut pour les nouveaux workflows. Pour les nouvelles installations de serveur ou les nouveaux employés sur des serveurs existants, la valeur par défaut est d'autoriser l'exécution d'AMP et du moteur d'origine. Les paramètres de workflow déterminent le moteur utilisé. 

1.    Controller (Contrôleur) > General (Général) > Enable AMP Engine (Activer AMP Engine) 

      1.  Avant la mise à niveau, notez vos paramètres actuels.

      2. Après la mise à niveau, restaurez la sélection à la valeur souhaitée. 

2.    Worker > General (Général) > Allow Server to manage workflows running simultaneously (Autoriser Server à gérer les workflows s'exécutant simultanément) 

      1. Avant la mise à niveau, notez le nombre défini de workflows autorisés à s'exécuter simultanément.

       2. Après la mise à niveau, désélectionnez « Allow Server to manage workflows running simultaneously » (Autoriser Server à gérer les workflows s'exécutant simultanément).

       3. Entrez le nombre de workflows autorisés à s'exécuter simultanément que vous avez noté.

3.    Engine (Moteur) > General (Général) > Engine  (Moteur) 

     1. Avant la mise à niveau, notez vos paramètres actuels.

     2. Après la mise à niveau, restaurez la sélection à la valeur souhaitée. 

4    .Engine (Moteur) > General (Général) > Run engine at a lower priority (Exécuter le moteur en basse priorité)

      1. Avant la mise à niveau, notez vos paramètres actuels.

      2. Après la mise à niveau, restaurez la sélection à la valeur souhaitée. 

We recommend you use the new options Allow Server to manage workflows running simultaneously and Allow Server to manage engine resources. We've added logic to keep each engine instance working within the memory and logical CPU constraints defined in the System Settings. Admins must take care not to over-allocate if they set these values manually instead of allowing Server to manage them. 

Calculations

When you enable the options to Allow Server to manage workflows running simultaneously and Allow Server to manage engine resources, Server calculates the number of simultaneous jobs, as well as the CPU threads (cores) and amount of memory to allocate per job at service startup. These calculations are based on total available logical CPU cores and total system memory resources on the host machine. They are also designed to optimize AMP performance for the available hardware based on our benchmarking results. The formulas for those calculations are as follows:

Recommendations for Manual Value Setting

We recommend you follow these guidelines for optimal performance when setting these values manually:

• Memory per running workflow: 8GB per workflow is the minimum recommendation for optimal performance with AMP.
• CPU per running workflow: 1 simultaneous running workflow per 6-8 logical CPU cores.
• Maximum number of AMP engines run in parallel: This is entirely hardware dependent. In theory, you could run 16 AMP or mixed AMP and original Engine jobs at once if you had a worker with 128 logical cores and 160GB of RAM. Although, at this point disk I/O and network bandwidth are more likely to end up being the bottleneck. Both the original Engine and AMP will be performance limited by disk I/O and network bandwidth depending on the size of the data and where it is coming from and being output to.
• Max number of AMP engines run while also running E1: Server doesn’t differentiate between an AMP engine and an original Engine job. Server just sends the workflow to Engine and Engine determines if it needs to run via AMP or original Engine. As such Server assumes all jobs are AMP if AMP engine is enabled.

We recommend that you reserve 1 job's worth of memory for the operating system and an additional job's worth of memory to avoid a negative impact if you manually run a workflow from Designer running on the Server. Our formulas to calculate resources already take these recommendations into consideration.

For the latest Server System Requirements, see the Server System Requirements help page. We’ve separated our recommendations into 2 different categories: Minimum Hardware Requirements and Recommended Hardware for Optimal Performance. 

Minimum Hardware Requirements

Server minimum hardware requirements are defined as the minimum hardware needed to run a stable installation of Alteryx Server. If you don't meet the minimum requirements, you risk poor performance and random service shutdown on any node where the engine runs. 

The following minimum hardware requirements are recommended for the desired number of concurrent workflows:

Recommended Hardware for Optimal Performance

Server optimal performance hardware recommendations are defined as the sweet spot in hardware where Server can complete workflows as efficiently as possible when using the AMP engine. This is useful to eliminate congestion on busy systems and optimize AMP engine performance and throughput capabilities. 

We recommend the following hardware settings for optimal performance: 

1. Dans les versions antérieures à 2022.1, AMP était disponible sur Server, mais désactivé par défaut.
2. Pour la version 2022,1 et les versions ultérieures, pour les nouvelles installations de serveur, le contrôleur et le travailleur auront la valeur par défaut pour permettre l'exécution d'AMP et du moteur d'origine. Pour les serveurs existants, les paramètres de contrôleur et de travailleur existants peuvent changer et l'exécution AMP et celle du moteur d'origine des nouveaux employés peuvent être activées par défaut. Si vous souhaitez éviter cela, consultez notre note sur la façon de conserver les paramètres actuels. 
3. Les paramètres d'activation d'AMP Engine dans les nœuds de contrôleur et de worker se trouvent dans les paramètres système Alteryx. Il existe désormais des paramètres supplémentaires pour la gestion des allocations matérielles pour chaque moteur. Il existe également un paramètre recommandé pour autoriser Server à gérer les ressources du moteur. 
4. Paramètres système pour les installations de Server existantes : 
   1. Contrôleur>général>Activer AMP Enginesi vous avez déjà modifié cette valeur, quelle que soit la valeur que vous avez remplacée, cette valeur persiste après la mise à niveau. Si vous n'avez jamais modifié ce paramètre et que vous n'avez toujours pas sélectionné l'état par défaut, la case à cocher est alors sélectionnée, ce qui signifie que l'AMP est activé par défaut. 
   2. Le paramètre Worker> General> Allow Server to manage workflows running simultaneously prend par défaut la valeur True pour tous les workers. Lorsque ce paramètre est défini sur vrai, vous ne pouvez pas définir le nombre de travailleurs autorisés à s'exécuter simultanément. 
      1. Le nombre de workers pouvant s'exécuter simultanément (Workers allowed to run simultaneously) est automatiquement calculé au démarrage du service en fonction du processeur et de la mémoire disponibles dans l'environnement Server. 
         
   3. Engine> General> Engine : si le client a déjà changé cette valeur, la nouvelle valeur sera persistante après la mise à niveau, et ce quelle que soit la modification. Si le client n'a jamais modifié ce paramètre et a toujours utilisé l'option par défaut du moteur d'origine, la nouvelle valeur par défaut sera définie sur les deux moteurs. 
   4. Engine> General> Allow Server to manage engine resources est un nouveau paramètre qui est défini par défaut sur False. 
      
   5. Engine> General> Memory Limit : formule qui permet de calculer la valeur par défaut a changé. 
   6. Engine> General> Default number of processing threads : formule qui permet de calculer la valeur par défaut a changé. 
   7. Engine> General> Run engine at a lower priority : si le client a déjà changé cette valeur, la nouvelle valeur sera persistante après la mise à niveau, et ce quelle que soit la modification. Si le client a toujours utilisé la valeur par défaut False, après la mise à niveau, la nouvelle valeur par défaut sera définie sur True.
5. Paramètres système pour les nouvelles installations de Server :
   1. La case à cocher Controller> General> Enable AMP Engine est par défaut définie sur True. 
   2. Le paramètre Worker> General> Allow Server to manage workflows running simultaneously prend par défaut la valeur True pour tous les workers. 
      1. Le nombre de workers pouvant s'exécuter simultanément (Workers allowed to run simultaneously) est automatiquement calculé au démarrage du service en fonction du processeur et de la mémoire disponibles dans l'environnement Server. 
   3. La liste déroulante Engine> General> Engine affiche par défaut Both Engines. 
   4. Le paramètre Engine> General> Allow Server to manage engine resources est défini par défaut sur False. 
   5. Engine> General> Memory Limit : formule qui permet de calculer la valeur par défaut a changé. 
   6. Engine> General> Default number of processing threads : formule qui permet de calculer la valeur par défaut a changé. 
   7. Le paramètre Engine> General> Run engine at a lower priority est défini par défaut sur True. 
6. Les utilisateurs peuvent-ils rétablir les paramètres modifiés (c.-à.-d., désactiver AMP dans Server) ?
   1. Si l'administrateur ne veut pas utiliser AMP, il doit le désactiver manuellement. Voir l'image ci-dessous pour visualiser le paramètre Engine dans la section Configuration générale du contrôleur des paramètres système.
      
   2. Si l'administrateur souhaite désactiver AMP sur certains nœuds de worker, il peut procéder à l'opération dans la section Configuration du moteur des paramètres système. Voir ci-dessous la liste déroulante du paramètre Engine. Dans l'image ci-dessous, il est défini sur Both Engines, mais peut être modifié pour sélectionner le moteur d'origine Original Engine uniquement. Both Engines est la valeur par défaut dans un nouvel environnement Server.
      

• Il n'y a pas de limite de mémoire distincte. Dans Paramètres système, le champ Engine> General> Memory Limit s'applique au moteur. Il s'applique à la fois à Designer et Server, soit à toute application où le moteur s'exécute.
• Designer n'exécute qu'un seul workflow à la fois. Les limitations sont donc différentes et plus tolérantes.

AMP est automatiquement activé sur le système et tous les paramètres pertinents sont configurés par défaut. Les modifications sont uniquement nécessaires s'ils souhaitent le désactiver. Reportez-vous aux réponses de la section Quelles sont les modifications apportées à Designer et à Server ?

Assurez-vous de respecter les directives de la  configuration matérielle minimale requise pour des performances et une stabilité optimales.

L'activation d'AMP dans Server entraînera-t-elle l'échec de l'un de mes workflows existants ? 

• Non, ils s'exécuteront exactement de la même manière qu'auparavant.

L'exécution d'AMP et du moteur d'origine sur le serveur modifiera-t-elle la façon dont mes flux de travail existants s'exécutent ? 

• Lorsqu'un workflow est enregistré dans Designer, l'option de paramètre Exécution est d'utiliser AMP Engine ou non. Quelle que soit l'option enregistrée dans Designer, elle est prise en compte lors de l'exécution dans Server. Server ne remplace jamais l'option de moteur du workflow. Par conséquent, si vous autorisez à la fois l'exécution de l'AMP et du moteur d'origine sur le serveur, aucun flux de travail enregistré comme moteur d'origine ne sera exécuté avec le AMP Engine. Si un flux de travail est enregistré avec AMP comme option de moteur et qu'AMP n'est pas activé dans le serveur, le flux de travail NE s'exécutera pas comme moteur d'origine et échouera. 
• Pour qu'un flux de travail précédemment enregistré comme moteur d'origine s'exécute en tant qu'AMP, le flux de travail doit être enregistré à nouveau dans Designer avec le paramètre utiliser AMP Engine sélectionné. 
• L'exécution de workflows dans AMP peut modifier l'ordre des lignes de sortie résultantes, car certaines opérations sont désormais effectuées en parallèle. Gardez cela présent à l'esprit et vérifiez si vos processus dépendent de l'ordre de sortie. Si c'est le cas, des ajustements peuvent être apportés à vos flux de production pour garantir l'ordre du moteur d'origine.

• Vous pouvez vous attendre à des changements concernant la durée d'exécution de chaque workflow.
• En général, les tâches de workflow AMP s'exécuteront beaucoup plus rapidement avec le nombre de cœurs de traitement approprié.
• Dans certains cas, les travaux AMP peuvent prendre plus de temps que les travaux du moteur d'origine, en particulier si les flux de production sont gourmands en CPU et que le nombre de threads par flux de production est faible.
• Bien qu'en général, le délai d'exécution de vos workflows sera plus court, l'exécution d'un workflow non-AMP pourra être plus long, puisqu'un workflow AMP concurrent lui prendra des ressources. Cependant, cela n'a aucune incidence sur le fonctionnement de la qualité de service (QoS) et certains workflows pourront s'exécuter plus rapidement. La QoS continuera de fonctionner comme elle l'a toujours fait.

Cela est-il envisageable lorsqu'AMP est activé ?

• Le délai de réalisation devrait toujours être meilleur, à quelques exceptions près, où la synchronisation est plus longue.

Si l'activation d'AMP ne permet plus de garantir des délais d'exécution constants, faut-il recommander aux utilisateurs concernés de désactiver AMP ?

• S'il dispose de ressources suffisantes, les flux de travail AMP et Original Engine doivent être prévisibles (prévisibles à l'aide d'une nouvelle référence, au lieu de ne pas se limiter aux résultats historiques des performances du moteur d'origine). La seule fois où cela deviendrait imprévisible est si les ressources matérielles d'un travailleur sont sous-allouées (moteur d'origine et AMP en concurrence pour les ressources).

Il est possible d'enregistrer le workflow sur Server avec AMP activé, puis d'en enregistrer une copie avec AMP désactivé. Exécutez ensuite plusieurs fois chaque workflow pour identifier le plus performant. Notez également que les workflows AMP ont tendance à s'exécuter plus rapidement lorsqu'ils sont exécutés en même temps que d'autres workflows AMP.

La limite de mémoire de configuration du moteur s'applique au moteur, qu'il soit d'origine ou AMP. La différence réside dans la façon dont chaque moteur gère la limite de mémoire :

• Le moteur d'origine préalloue la totalité de la limite.
• Le moteur AMP alloue ce dont il a besoin jusqu'à la limite de mémoire. 

L'utilisation des ressources est plus efficace. Le moteur d'origine est multithread, mais pas hautement multithread. AMP est bien plus performant pour exécuter des tâches en série. Les avantages sont le débit total, qui est plus élevé avec AMP que lorsque vous utilisez le moteur d'origine.

Server est désormais capable d'analyser votre matériel et d'allouer les ressources appropriées par moteur. Cette capacité n'est pas du même niveau que celle d'un gestionnaire de ressources de système d'exploitation. Néanmoins, grâce à cette nouvelle fonctionnalité, Server est maintenant capable de gérer vos ressources.

Si l'administrateur le configure, nous allouons automatiquement le nombre de tâches autorisées à s'exécuter simultanément en fonction des ressources matérielles disponibles. Pour plus d'informations sur la configuration des workers, reportez-vous à la page d'aide Worker. 

Non, les ressources sont allouées par tâche de moteur. Chaque tâche se voit allouer ses propres ressources. Cela signifie qu'il ne doit pas exister de conflit de ressources entre les tâches.