L'exécution d'une session Optimize prend beaucoup de temps

Voici des étapes de traitement des incidents que vous pouvez suivre si vous pensez que l'exécution de votre session Optimize prend trop de temps.

Avant de commencer

1.	Vérifiez que la session ne s'exécute pas avec Optimize\|Debug\|ExtraVerbose activé car ce paramètre entraîne des temps importants d'exécution. Vérifiez les paramètres avancés de niveau session et les propriétés de configuration.

2.	Assurez-vous que vous utilisez un chargeur de base de données et que celui-ci est correctement configuré.

3.	Si vous utilisez des intervalles de temps avec vos règles, vérifiez que les tables d'historique des contacts pour votre niveau d'audience sont indexées.

4.	Définissez Optimize\|Logging\|loggingLevels sur MEDIUM ou LOW. Vérifiez les paramètres avancés de niveau session et les propriétés de configuration.

Exécutez une session pour générer un journal propre pour le traitement des incidents.

Si l'exécution de votre session Optimize dure longtemps après les étapes suivantes de la section Avant de commencer, vous devez collecter des informations détaillées à analyser.

Exécutez une session pour générer un journal propre du serveur Optimize avec le paramètre HIGH ou ALL activé. Pendant que votre session s'exécute, n'accédez pas à des rapports Optimize car cette action ajoute au journal des données qui peuvent rendre la situation plus confuse. Cette session peut prendre plus de temps pour s'exécuter car vous collectez des données de journal détaillées. Pensez à redéfinir Optimize|Logging|loggingLevels sur MEDIUM ou LOW après avoir collecté un journal propre.

Une fois que vous avez généré un journal, vérifiez deux éléments :

Le temps consacré à l'accès à la base de données pour configurer les données nécessaires pour la session.

Le temps consacré au traitement des échantillons client (blocs).

Comment vérifier le temps passé à accéder à la base de données

En utilisant le journal propre que vous avez généré, procédez comme suit pour déterminer combien de temps Optimize met pour accéder à la base de données afin de configurer les données nécessaires pour la session.

1.	Dans le journal du serveur Optimize, recherchez la chaîne LRE Starting chunk: 0

2.	Notez l'horodatage de cette entrée et soustrayez-le de l'horodatage de la première entrée du journal. La différence représente le temps passé à accéder à la base de données pour configurer les données nécessaires pour exécuter la session.

Si la valeur semble trop élevée, examinez les horodatage de début et de fin pour les requêtes correspondant à la section de journal précédant LRE Starting chunk: 0 pour identifier la requête qui prend trop de temps.

3.	Ensuite, traitez les incidents pour la tâche qui a pris trop de temps comme vous le feriez pour tout problème de performance de base de données.

Comment vérifier le temps passé à traiter les échantillons client (blocs)

En utilisant le journal propre que vous avez généré, procédez comme suit pour déterminer combien de temps Optimize met pour traiter les échantillons client.

Dans le journal du serveur Optimize, soustrayez l'horodatage de la ligne correspondant à LRE Starting chunk: 0 de l'horodatage de la ligne correspondant à Run Thread terminated.

Cette entrée de journal vous indique le temps passé total de la section CPU-intensive optimization (optimisation de l'utilisation intensive des ressources processeur). Si la majeure partie du temps est consacrée à cette action, vous pouvez mieux vous rendre compte de ce qui se passe en examinant les itérations de bloc.

Vous trouverez la solution optimale pour chaque bloc en effectuant des itérations des étapes suivantes :

1.	Appliquer un ensemble de scores aux offres de ce bloc

2.	Rechercher les solutions optimales avec ces scores pour les clients du bloc à l'aide de l'algorithme principal.

3.	Utiliser le résultat de l'algorithme externe pour trouver un nouvel ensemble de scores à essayer.

Chaque fois qu'Optimize applique un ensemble de scores, cela compte comme une itération de bloc. Le temps passé dans la section CPU-intensive est approximativement proportionnel au nombre moyen d'itérations par bloc.