Ecart majeur de temps d'import XML entre environnements

Bonjour,

Je cherche à ingérer des données depuis un fichier CSV de 32 000 lignes. Celui-ci prend trop de temps à ingérer donc je l’ai découpé en 16 pour tester. Entre notre environnement sur AWS et celui sur votre cloud, on constate une grosse différence de temps qu’on cherche à corriger.

Sur votre cloud, l’ingestion d’un de ces 16e de fichier (2000 lignes, 500 Ko) prend un peu moins de deux minutes. Sur notre environnement, il prend entre 35 minutes et 2 heures.

Je suis allé investiguer auprès de notre équipe dev ops en soupçonnant que la db avait soit un pool de connexions sous dimensionné, soit un problème réseau. Après vérifications rapides, mon interlocuteur dev ops me dit qu’il ne devrait pas y avoir de problèmes et que le nombre de connexions est paramétré au niveau du tomcat.

Le fait est que j’ai testé l’import sur les deux environnements (votre cloud : 2 minutes vs le notre : 35 à 120 minutes) avec le même jeu de test (2000 lignes, 500 Ko) et le même adapter/modèle de données ; et que les deux, à ma connaissance, utilisent le même dockerfile (release). Les différences sont au niveau de la db utilisée (HSQL vs PGSQL), le dimensionnement de la ram et du disque.

Je colle le health des deux environnements à ce message (Health cloud Simplicité pour votre environnement qui process le fichier en 2 minutes ; Health AWS pour le notre qui prend 20 à 60 fois plus de temps)

Est-ce que vous savez quel paramétrage peut engendrer de telles différences de performances et si oui comment les vérifier afin que nous puissions revenir vers notre équipe dev ops et leur démontrer que le problème vient bien de chez nous et comment le corriger.

Merci d’avance.

Health Cloud Simplicité


[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-06-24 12:02 (revision 37bff5123e5689935ee77c91105f31c1cf3a1f5c)
Encoding=UTF-8
EndpointIP=149.202.171.75
EndpointURL=https://renault.simplicite.io:10283
TimeZone=Europe/Paris
SystemDate=2019-06-26 19:14:38

[Application]
ApplicationVersion=0.16 dev
ContextPath=
ContextURL=https://sitesdev.renault.simplicite.io
ActiveSessions=6
EnabledUsers=10
TotalUsers=15
LastLoginDate=2019-06-26 18:52:48

[Server]
ServerInfo=Apache Tomcat/9.0.21
ServerType=WEB
User=sitesdev

[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-957.12.2.el7.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=24101
DiskUsable=21992
DiskTotal=50286

[JavaVM]
Version=1.8.0_212
Vendor=Oracle Corporation
VMName=OpenJDK 64-Bit Server VM
VMVersion=25.212-b04
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=129802
HeapSize=373760
HeapMaxSize=466432
TotalFreeSize=222474

[Cache]
GrantCache=21
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=143
ObjectCacheMax=10000
ObjectCacheRatio=1
ProcessCache=0
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=1
ProductName=HSQL Database Engine
ProductVersion=2.4.1
DriverName=HSQL Database Engine Driver
DriverVersion=2.4.1
DBDate=2019-06-26 19:14:38.050000+2:00
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=false

[Healthcheck]
Date=2019-06-26 19:14:38
ElapsedTime=120

Health AWS


[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-06-24 12:02 (revision 37bff5123e5689935ee77c91105f31c1cf3a1f5c)
Encoding=UTF-8
EndpointIP=172.17.0.22
EndpointURL=http://12d81b031d6d:8080
TimeZone=Europe/Paris
SystemDate=2019-06-26 19:14:48

[Application]
ApplicationVersion=0.16 dev
ContextPath=
ContextURL=https://int.rfs.dev.aws.renault.com
ActiveSessions=1
EnabledUsers=10
TotalUsers=11
LastLoginDate=2019-06-26 18:52:21

[Server]
ServerInfo=Apache Tomcat/9.0.21
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=4.14.101-75.76.amzn1.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=9143
DiskUsable=8615
DiskTotal=10015

[JavaVM]
Version=1.8.0_212
Vendor=Oracle Corporation
VMName=OpenJDK 64-Bit Server VM
VMVersion=25.212-b04
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=71520
HeapSize=506944
HeapMaxSize=1773888
TotalFreeSize=1338464

[Cache]
GrantCache=103
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=132
ObjectCacheMax=10000
ObjectCacheRatio=1
ProcessCache=0
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=3
ProductName=PostgreSQL
ProductVersion=10.6
DriverName=PostgreSQL JDBC Driver
DriverVersion=42.2.5.jre7
DBDate=2019-06-26 19:14:48
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-06-26 19:14:48
ElapsedTime=110

Un HSQLDB embedded sera forcément plus rapide qu’un PostgreSQL externe mais là la différence me semble énorme.

Pour ce qui est de la taille du datasource on laisse les valeurs par défaut:

<Resource
		name="jdbc/simplicite"
		type="javax.sql.DataSource"
		auth="Container"
		username="${postgresql.user}"
		password="${postgresql.password}"
		driverClassName="org.postgresql.Driver"
		url="jdbc:postgresql://${postgresql.host}:${postgresql.port}/${postgresql.database}">

Si j’en crois la doc Tomcat (cf. Apache Tomcat 9 (9.0.76) - The Tomcat JDBC Connection Pool) ça peut monter jusqu’à 100 donc pas de pb à ce niveau.

Ce qui peut jouer sur les performances c’est:

  • La puissance allouée au container Tomcat
  • Les latences réseau entre le container Tomcat et la base de données
  • La puissance allouée à la base de données
  • L’indexation de la base sur tes objets métier

Sur les 3 premiers points c’est vous qui savez / qui pouvez investiguer (par exemple en instanciant un container éphémère avec une base HSQLDB embedded pour avoir une vraie base de comparaison)

Sur le dernier point, normalement les indexes sont créés à la volée à la création ou import du paramétrage, mais peut être y a-t-il eu un pb à ce niveau. Pour forcer leur (re)création tu peux aller dans Administration > Business object, rechercher tes objets et lancer l’action Indexes proposal (qui ne fait plus que les proposer, mais qui les recrée):

Dans le monitoring tu peux tracer les temps des requêtes les plus coûteuses, pour cela il faut démarrer le monitoring (Start):

Ensuite, apès avoir un peu navugué dans la UI, tu auras les stats en question tout en base dans l’onglet Data: