Nombre de threads optimum

L'exécution d'un processus en arrière-plan sur plusieurs threads est presque toujours plus rapide que de l'exécuter en un seul thread. L'astuce est de déterminer le nombre de threads optimum pour chaque processus.

Remarque :
Une des meilleures règles est d'avoir un thread pour chaque 100 MHz de CPU disponibles sur le serveur d'applications. Par exemple, si vous avez quatre processeurs de 450 MHz disponibles sur votre serveur d'applications, vous pouvez commencer avec 18 threads pour lancer vos tests : (450 * 4) / 100 = 18.

Il s'agit d'une des meilleures règles car chaque processus est différent et dépend des données de votre base de données. Votre configuration matérielle (c.-à-d., le nombre de processeurs, la vitesse de vos disques durs, la vitesse du réseau entre la base de données et le serveur d'applications) a aussi un impact sur le nombre optimum de threads. Suivez les conseils ci-dessous pour déterminer le nombre optimum de thread pour chaque processus en arrière-plan :

  • Exécutez le processus en arrière-plan en utilisant le nombre de threads défini par la meilleure règle (décrite ci-dessus). Lors de cette exécution, contrôlez le pourcentage d'utilisation de votre serveur d'applications, de votre serveur de base de données et du trafic du réseau.

  • Si votre serveur de base de données est utilisé à 100 %, mais votre serveur d'applications ne l'est pas, l'une des hypothèses suivantes a pu se produire :

    • Une instruction SQL pose probablement problème lors de l'exécution du processus. Vous devez capturer une trace de la base de données afin d'identifier le problème SQL.

    • Il est aussi possible que la fréquence de validation (commit) soit trop importante. Ce paramètre est spécifié pour chaque processus en arrière-plan. Si sa valeur est trop élevée, les files d'attente de la base de données peuvent commencer à permuter. Pour plus d'informations sur ce paramètre, voir Paramètres spécifiés pour les processus en arrière-plan.

  • Il est normal que l'utilisation de votre serveur d'applications atteigne 100 %, mais pas votre serveur de base de données. Cela est normal car, en règle générale, tous les processus sont "CPU-bound" mais non "IO-bound". A ce point, vous devez diminuer le nombre de threads jusqu'à ce que le pourcentage d'utilisation de votre serveur d'applications soit juste inférieur à 100 %. Et cela correspondra au nombre optimum de threads requis pour le processus en arrière-plan.

  • Si vous découvrez que l'utilisation de votre serveur d'applications n'atteint pas 100 %, vous devez augmenter le nombre de threads jusqu'à ce que le pourcentage d'utilisation du serveur d'applications soit juste inférieur à 100 %. Notez aussi que l'utilisation du serveur d'applications doit atteindre 100 % avant que l'utilisation du serveur de base de données n'atteigne 100 %. Si tel n'est pas le cas, une instruction SQL pose probablement problème et vous devez capturer une trace SQL afin de déterminer l'instruction posant problème.

Une autre manière d'obtenir des résultats similaires est de commencer avec un petit nombre de threads et d'augmenter le nombre de threads jusqu'à ce que vous obteniez le meilleur débit. La définition de "débit" peut être différente pour chaque processus, mais peut aussi être généralisée comme simple nombre d'enregistrements traités dans l'exécution de batch. Par exemple, dans le processus en arrière-plan de facturation dans Oracle Utilities Customer Care and Billing, le débit correspond au nombre de factures traitées par minute. Si vous choisissez d'utiliser cette méthode, nous vous conseillons de créer un graphique indiquant la relation entre le débit et le nombre de threads. Ce graphique doit afficher une courbe s'élevant très rapidement puis s'aplanissant lorsque d'autres threads sont ajoutés. L'ajout d'autres threads peut éventuellement entraîner un ralentissement du débit. Par ce type d'analyse, vous pouvez déterminer le nombre optimum de threads pour l'exécution d'un processus donné.