Performance – TOP 5 – Mauvaise utilisation de la base de données

Parmi les problèmes de performance communément admis, il y a ceux qui relèvent d’une utilisation incorrecte de la base de données. Cette catégorie regroupe beaucoup de mauvaises pratiques qui ont des impacts plus ou moins importants sur la performance des applications. On peut citer par exemple les problèmes liés à la conception de la base de données jusqu’à l’utilisation inappropriée des librairies de mapping ORM (object-relational mapping).

C’est à cette dernière typologie de mauvaises pratiques que j’ai récemment été confronté. Je suis intervenu sur l’étude du dimensionnement de l’infrastructure de déploiement d’une application en vue de sa généralisation sur un plan national. Avant de dimensionner l’infrastructure, je me suis assuré de la capacité à monter en charge du produit (c’est à dire de la capacité de l’application à exposer un fonctionnement nominal lorsque le niveau de sollicitation augmente).

En bref, celle ci ne montait pas en charge et plusieurs facteurs ont rapidement été identifiés. Parmi eux l’exécution unitaire d’un workflow applicatif, aussi complexe était il, générait plus de 20000 requêtes sur la base de données. On conçoit tout naturellement que cette sur utilisation de la base de données puisse générer quelques perturbations lorsque l’application traite de plus en plus de d’invocations de service.

L’analyse macroscopique des requêtes montrait non seulement qu’une grande quantité d’ordres SQL identiques portait sur des informations référentielles mais également un requêtage qui semblait récupérer des graphes de données.

La première des solutions que nous avons apporté à ce type de dysfonctionnement consistait à configurer la mise en cache des données référentielles réputées stables. Bien entendu il est important dans ce type d’actions d’approfondir la réflexion en s’interrogeant, pour chaque cas, à la durée de rétention de l’information, sa volumétrie, les impacts d’une information obsolète, l’efficacité du cache (hit ratio)…

Cependant avant de procéder à ces premiers ajustements, nous nous sommes interrogés également sur les relations entre les entités du modèle. En effet, la modélisation des données comportait beaucoup de relations de type «  OneToOne   » et «   ManyToOne   ». Nous avons également constaté que le modèle objet de l’application était très riche et comportait de nombreuses relations entre les entités. Par ailleurs l’ORM (EclipseLink) utilisé par le produit, chargeait agressivement ces deux types de relations.

Par conséquent, le chargement d’une entité résultait sous l’effet conjugué des liaisons entre les objets, de la nature des relations et de l’implémentation par défaut de l’ORM, par le chargement d’un graphe important d’objets souvent utilisé partiellement (et donc par la génération d’une multitude de requêtes sur la base de données).

La date de généralisation de l’application étant relativement proche, la solution qui a été apportée à cette problématique était d’interrompre le chargement agressif des données au profit d’un chargement à la demande et de réaliser cette intervention uniquement lorsque cela ne dégradait pas les fonctionnalités exposées par l’application. D’autres stratégies de chargement peuvent être utilisées pour améliorer l’accès aux données mais elles n’étaient pas efficaces dans notre cas de figure.

Une fois cette action réalisée et combinée à l’efficacité de la mise en cache des données référentielles, le nombre de requêtes sur la base de données a été divisé par un 7 (soit environ 3000 requêtes pour chaque exécution du workflow). De fait, les temps de réponse de l’application sont devenus plus stables, l’utilisation de la mémoire a légèrement augmenté au profit d’un cycle de récupération de la mémoire par la machine virtuelle moins pénalisant, et nous avons constaté que l’utilisation des ressources physiques des serveurs était beaucoup moins intense. Certes le travail d’optimisation de l’accès aux données aurait pu être complété et il reste des axes de travail intéressants mais ces actions n’étaient pas compatibles avec le calendrier de déploiement du projet. Ces pistes de travail se sont donc ajoutées à la dette technique de l’application mais le dimensionnement de l’infrastructure a pu être réalisé pour atteindre les objectifs de disponibilité du produit.

http://www.jperf.com

Publicités

A propos jlerbsc

founder of JavaPerf Consulting Http://www.jperf.com
Cet article, publié dans performance, est tagué , . Ajoutez ce permalien à vos favoris.

Un commentaire pour Performance – TOP 5 – Mauvaise utilisation de la base de données

  1. Ping : Mauvaise utilisation de la base de données | Experts Performance : Le site dédié à l’expert en performance

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s