Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisation du cache d'exécution
Par défaut, les exécutions n'utilisent pas de cache d'exécution. Pour utiliser un cache pour l'exécution, vous devez spécifier le cache d'exécution et le comportement du cache d'exécution lorsque vous démarrez l'exécution.
Une fois l'exécution terminée, vous pouvez utiliser la console, les CloudWatch journaux ou les opérations de l'API pour suivre les accès au cache ou résoudre les problèmes liés au cache. Pour plus d’informations, consultez [Suivi des informations de mise en cache des appels](#workflow-cache-track) et [Résolution des problèmes de mise en cache des appels](troubleshooting.md#workflow-cache-troubleshooting).
Si une ou plusieurs tâches d'une exécution génèrent des résultats non déterministes, nous vous recommandons vivement de ne pas utiliser la mise en cache des appels pour l'exécution ou de désactiver ces tâches spécifiques de la mise en cache. Pour de plus amples informations, veuillez consulter [Modèle de responsabilité partagée](how-run-cache.md#run-cache-srm).
**Note**
Vous fournissez un rôle de service IAM lorsque vous lancez une exécution. Pour utiliser la mise en cache des appels, le rôle de service doit être autorisé à accéder à l'emplacement du cache d'exécution Amazon S3. Pour de plus amples informations, veuillez consulter [Rôles de service pour AWS HealthOmics](permissions-service.md).
Vous pouvez utiliser la [CLI Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) pour analyser et gérer les données de votre cache d'exécution. Pour plus d'informations, consultez les [exemples d'instructions pour Amazon Q CLI](getting-started.md#omics-q-prompts) et le didacticiel [HealthOmics Agentic Generative AI](https://github.com/aws-samples/aws-healthomics-tutorials/tree/main/generative-ai) sur. GitHub
**Topics**
+ [Configuration d'une exécution avec cache d'exécution à l'aide de la console](#workflow-cache-startrun-console)
+ [Configuration d'une exécution avec cache d'exécution à l'aide de la CLI](#workflow-cache-startrun-api)
+ [Cas d'erreur pour les caches d'exécution](#workflow-cache-errors)
+ [Suivi des informations de mise en cache des appels](#workflow-cache-track)
## Configuration d'une exécution avec cache d'exécution à l'aide de la console
Depuis la console, vous configurez le cache d'exécution pour une exécution lorsque vous démarrez l'exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Runs**.
1. Sur la page **Exécutions**, choisissez la course à démarrer.
1. Choisissez **Démarrer l'exécution** et effectuez les étapes 1 et 2 de **Démarrer l'exécution** comme décrit dans[Démarrer une course à l'aide de la console](starting-a-run.md#starting-a-run-console).
1. À l'étape 3 de **Démarrer l'exécution**, choisissez **Sélectionner un cache d'exécution existant**.
1. Sélectionnez le cache dans la liste déroulante **Run cache ID**.
1. Pour remplacer le comportement de cache d'exécution par défaut, choisissez le **comportement de cache** pour l'exécution. Pour de plus amples informations, veuillez consulter [Exécuter le comportement du cache](how-run-cache.md#run-cache-behavior).
1. Passez à l'étape 4 de **Démarrer l'exécution**.
## Configuration d'une exécution avec cache d'exécution à l'aide de la CLI
Pour démarrer une exécution utilisant un cache d'exécution, ajoutez le paramètre cache-id à la commande **start-run** CLI. Utilisez éventuellement le `cache-behavior` paramètre pour remplacer le comportement par défaut que vous avez configuré pour le cache d'exécution. L'exemple suivant montre uniquement les champs de cache de la commande :
```
aws omics start-run \
...
--cache-id "xxxxxx" \
--cache-behavior CACHE_ALWAYS
```
Si l'opération est réussie, vous recevez une réponse sans champs de données.
## Cas d'erreur pour les caches d'exécution
Dans les scénarios suivants, il est HealthOmics possible que les résultats des tâches ne soient pas mis en cache, même dans le cas d'une exécution avec un comportement de cache défini sur **Toujours mettre en cache**.
+ Si l'exécution rencontre une erreur avant que la première tâche ne soit terminée correctement, il n'y a aucune sortie de cache à exporter.
+ Si le processus d'exportation échoue, les résultats de la tâche HealthOmics ne sont pas enregistrés dans l'emplacement du cache Amazon S3.
+ Si l'exécution échoue en raison d'une **filesystem out of space** erreur, la mise en cache des appels n'enregistre aucun résultat de tâche.
+ Si vous annulez une exécution, la mise en cache des appels n'enregistre aucun résultat de tâche.
+ Si le délai d'exécution est dépassé, la mise en cache des appels n'enregistre aucun résultat de tâche, même si vous avez configuré l'exécution pour utiliser le cache en cas d'échec.
## Suivi des informations de mise en cache des appels
Vous pouvez suivre les événements de mise en cache des appels (tels que les accès au cache d'exécution) à l'aide de la console, de la CLI ou CloudWatch des journaux.
**Topics**
+ [Suivez les accès au cache à l'aide de la console](#workflow-cache-track-console)
+ [Suivez la mise en cache des appels à l'aide de la CLI](#workflow-cache-track-cli)
+ [Suivez la mise en cache des appels à l'aide des journaux CloudWatch](#workflow-cache-track-cwl)
### Suivez les accès au cache à l'aide de la console
Dans la page des détails de l'exécution d'une exécution, le tableau **Exécuter les tâches** affiche les informations relatives **aux accès au cache** pour chaque tâche. Le tableau inclut également un lien vers l'entrée de cache associée. Utilisez la procédure suivante pour afficher les informations relatives aux accès au cache lors d'une exécution.
1. Ouvrez la [HealthOmics console](https://console.aws.amazon.com/omics/).
1. Si nécessaire, ouvrez le volet de navigation de gauche (≡). Choisissez **Runs**.
1. Sur la page **Exécutions**, choisissez l'exécution à inspecter.
1. Sur la page des détails de l'exécution, choisissez l'onglet **Exécuter les tâches** pour afficher le tableau des tâches.
1. Si une tâche a un accès au cache, la colonne **Accès au cache** contient un lien vers l'emplacement d'entrée du cache d'exécution dans Amazon S3.
1. Cliquez sur le lien pour inspecter l'entrée du cache d'exécution.
### Suivez la mise en cache des appels à l'aide de la CLI
Utilisez la commande **get-run CLI** pour vérifier si l'exécution a utilisé un cache d'appels.
```
aws omics get-run --id 1234567
```
Dans la réponse, si le `cacheId` champ est défini, l'exécution utilise ce cache.
Utilisez la commande **list-run-tasks**CLI pour récupérer l'emplacement des données du cache pour chaque tâche mise en cache en cours d'exécution.
```
aws omics list-run-tasks --id 1234567
```
Dans la réponse, si le champ CacheHit d'une tâche est vrai, le champ Caches3URI indique l'emplacement des données du cache pour cette tâche.
Vous pouvez également utiliser la commande **get-run-task**CLI pour récupérer l'emplacement des données du cache pour une tâche spécifique :
```
aws omics get-run-task --id 1234567 --task-id
```
### Suivez la mise en cache des appels à l'aide des journaux CloudWatch
HealthOmics crée des journaux d'activité du cache dans le groupe de `/aws/omics/WorkflowLog` CloudWatch journaux. Il existe un flux de journal pour chaque cache d'exécution : **RunCache//**.
Pour les exécutions utilisant la mise en cache des appels, HealthOmics génère CloudWatch des entrées de journal pour les événements suivants :
+ création d'une entrée de cache (CACHE\$1ENTRY\$1CREATED)
+ correspondant à une entrée de cache (CACHE\$1HIT)
+ ne correspond pas à une entrée de cache (CACHE\$1MISS)
Pour plus d'informations sur ces journaux, consultez[Se connecte CloudWatch](monitoring-cloudwatch-logs.md#cloudwatch-logs).
Utilisez la requête CloudWatch Insights suivante sur le groupe de `/aws/omics/WorkflowLog` journaux pour renvoyer le nombre de visites au cache par exécution pour ce cache :
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_HIT'
parse "run: *," as run
stats count(*) as cacheHits by run
```
Utilisez la requête suivante pour renvoyer le nombre d'entrées de cache créées par chaque exécution :
```
filter @logStream like 'runCache//'
fields @timestamp, @message
filter logMessage like 'CACHE_ENTRY_CREATED'
parse "run: *," as run
stats count(*) as cacheEntries by run
```