[sdx-users] Retour sur les temps de suppression

[Martin Sevigny]

Bonjour,

Je reviens sur ce problème. Pour rappel, André Davignon a une
application avec 50 000 petits documents (références bibliographiques),
et il constate que la suppression est très lente:

-----
requête avec 5 réponses, puis suppression : temps de réponse 1min.
une requête avec 107 réponses, puis suppression : temps de réponse entre
25 et 30 min.
-----

J'ai récupéré son application et ses données. J'ai installé cela sur ce
SDX: http://www.ajlsm.com/download/sdx-22.war qui, pour rappel, est le
CVS du 20 octobre en branche 2.2, donc pas très loin de la 2.2.1 qui
sortira bientôt.

Autres infos techniques: Windows XP sur un ordinateur portable au disque
plutôt lent, Tomcat 5.0.28, Java 1.4.2_03.

J'ai indexé les 49232 documents en 5 lots de 10000 (sauf le dernier...),
ce qui a pris un total de 17 minutes et 9 secondes.

Ensuite je me suis amusé à supprimer des documents (c'est ça le but)
pour voir ce que ça donne...

... et c'est ce que je croyais: aucun problème. De l'ordre d'une seconde
ou deux, voire 4, que ce soit 1, 10 ou 100 documents à la fois. Normal
que ce soit semblable, ce qui prend du temps c'est la réoptimisation des
index et là ça ne change pas.

J'ai tout de même fait une modification à son application, et elle est
peut-être significative.

Celle-ci utilisait un entrepôt "FS" (filesystem), donc "système de
fichiers", ce qui signifie que SDX copie le fichier et le gère lui-même,
dans une hiérarchie de dossiers.

Personnellement, je n'ai même pas osé l'essayer sur mon ordinateur, je
sais par expérience que ce n'est pas très efficace. Et les entrepôts SDX
ne sont pas faits pour gérer un tel nombre de documents.

Donc premier conseil: utiliser les entrepôts FS uniquement pour de
petites bases, voire pour des tests.

J'ai utilisé un entrepôt MySQL:
<sdx:repository type="MYSQL" dsi="identifiant de la connexion"/>

Deuxième modification: les métadonnées associées à différents objets
(entrepôts, bases de documents, ...) sont gérés à l'aide d'une base de
données relationnelle par SDX. Par défaut, c'est HSQLDB qui est utilisé,
et les données sont dans conf/databases/_hsql.

Là aussi c'est pas trop mal, mais pour de grands volumes je préfère
confier cela à MySQL. Je n'ai pas testé avec HSQLDB l'application qui
nous concerne ici, donc je ne sais pas si c'était réellement un facteur...

Pour faire le changement, vous insérez cette ligne dans l'élément racine
du application.xconf:

<sdx:database type="MYSQL" dsi="identifiant de connexion"/>

où l'identifiant de connexion est bien sûr défini dans le cocoon.xconf.

J'ai utilisé la même base de données MySQL que pour l'entrepôt.

Bref, avec ces deux changements, tout fonctionne normalement. On peut
donc conclure que SDX peut gérer parfaitement de telles quantités de
données, y compris en suppression.

Maintenant, il faudrait qu'André fasse les mêmes changements pour voir
si ça règle son problème. Si oui, alors c'est bien cela, si non, alors
il y a un autre goulot d'étranglement qui est bien extérieur à SDX.

Il y a Dave Castonguay qui avait, je crois, des problèmes similaires.
Est-ce que c'est possible de faire les mêmes changements de configuration?

En gros, voici comment procéder.

1) Installez MySQL, si vous n'avez pas déjà un accès défini

2) Créez une base de données sur ce serveur MySQL, et ayez au moins un
utilisateur qui a tous les droit sur cette base. Je vais supposer que le
nom de la base est "sdx", l'utilisateur est "sdx" et le mot de passe
"sdx" pour le reste...

3) Dans le cocoon.xconf, répérez la ligne où c'est inscrit "datasources"
en commentaires, si vous n'avez jamais configuré des sources données
JDBC alors il n'y a rien d'autre que ce commentaire.

4) Inscrivez ceci sous cette ligne:
<datasources>
  <jdbc name="ma_db" logger="sdx.rdbms.ma_db">
    <pool-controller min="5" max="10"/>
    <dburl>jdbc:mysql://localhost:3306/sdx?autoReconnect=true</dburl>
      <user>sdx</user>
      <password>sdx</password>
  </jdbc>
</datasources>

5) Dans le fichier WEB-INF/web.xml, vous devez avoir ces lignes (non
commentées):
<init-param>
  <param-name>load-class</param-name>
  <param-value>
    org.gjt.mm.mysql.Driver
  </param-value>
</init-param>

Voilà, c'est tout je crois. Redémarrez Tomcat bien sûr pour bien
relancer tout cela. Vérifiez les logs pour être certain que rien n'a été
oublié.

A bientôt,

Martin Sévigny