Discussion :

[rami25316]

Bonjour,

Mon application charge un fichier Excel de 37124 lignes et pour chacune de ces lignes, il fait plusieurs requêtes (select) dans la BDD.

Mon problème est qu'au bout de plusieurs minutes (près d'une heure) de traitement le navigateur m'affiche:

Internet Explorer ne peut pas afficher cette page Web

Cependant je constate que l'application continue à fonctionner (les requêtes SQL sont toujours affichées dans la console d'Eclispe).

Le traitement se fait via une requête AJAX sur un serveur Tomcat v6 avec la JDK 1.5.0_22. Les requêtes SQL se font via Hibernate.

Je ne vois pas quoi modifier pour résoudre ce problème. Avez-vous des idées ?

Merci d'avance pour votre aide.

[OButterlin]

Tu peux jouer sur le timout de la réponse, tu peux regarder ici...
Ceci dit, 1h pour une requête, c'est excessivement long, aucun utilisateur normalement constitué n'acceptera cette longueur...
Que dois-tu faire au juste ? Enrichir un fichier xls ?

[rami25316]

J'ai un fichier Excel qui contient des lignes qui sont testées (chaque ligne entraîne une requête dans la BDD pour le test).
Une fois le fichier validé, les lignes sont ajoutées dans la BDD (c'est le but de l'application).

Afin d'éviter les timeout de la requête qui est faite via AJAX, j'ai fais en sorte que le serveur renvoie un le numéro de ligne qui est traitée ce qui permet de faire patienter l'utilisateur.

Je suis d'accord avec toi le temps d'attente pour l'utilisateur est très long mais mon problème pour l'instant c'est l'affichage du message d'erreur par le navigateur.

J'ai regardé ton lien mais je ne trouve rien qui améliore ma situation....

Merci de ton aide as tu d'autres idées ?

[OButterlin]

En résumé, tu fais un upload d'un fichier excel (gros à priori) et tu traites les lignes de ce dernier pour l'intégrer à ta base de données, on est d'accord ?
J'aurais tendance à utiliser un <iframe> masqué (style="display:none") pour l'envoi du fichier (c'est peut-être ce que tu fais déjà), du coup, tu pourrais utiliser tes requêtes ajax périodiques dans la partie "visible" de la page.

Sinon, ton problème de timeout est certainement lié au navigateur. Du coup, ça se complique, chaque navigateur a sa façon de gérer le timeout.
Tu as ici une procédure pour IE et là pour Firefox... mais bof...

[rami25316]

Je me suis fait la même réflexion que toi sur le timeout lié au navigateur.

Sachant que l'application n'est utilisable qu'avec IE saurais-tu comment modifier le timeout de ce navigateur. En cherchant sur Google, j'ai trouvé une méthode consistant à modifier les registres, ce qui ne m'inspire pas confiance cf: http://support.microsoft.com/kb/813827/fr).

Pour ce qui est des requêtes AJAX périodiques, je n'ai pas bien compris ce que tu me conseillais de faire, peux-tu me réexpliquer ?

P.S: merci encore pour ton aide

[OButterlin]

J'avais mis des liens sur "ici" et "là", tu n'as pas vu ?
Voici un extrait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Je résous le problème moi-mêmePour changer le  délai d'attente par défaut pour Internet Explorer 4.0 Service Pack 1  (SP1), ou version ultérieure, procédez comme suit :  
Démarrez l'Éditeur du Registre.
Recherchez la sous-clé suivante :HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Dans cette sous-clé, ajoutez une entrée DWORD ReceiveTimeout  dont la valeur équivaut à (<nombre_secondes>)*1 000. Par exemple,  pour un délai de 8 minutes, définissez la valeur de l'entrée ReceiveTimeout sur 480 000 (<480>*1 000).
Redémarrez l'ordinateur.

Pour la solution ajax périodique :

- la servlet traite un enregistrement et inscrit un statut dans une variable de session (ensuite, elle passe au suivant etc...)
- tu fais un appel ajax toutes les n secondes (à toi de voir) pour récupérer ce statut et l'afficher

[rami25316]

Je n'avais effectivement pas vue tes liens
Je vais essayer de faire les modifications appropriées merci.

[plawyx]

mon application charge un fichier Excel de 37124 lignes et pour chacune de ces lignes,

Est-ce qu'au niveau des traitements, les lignes sont indépendantes les unes des autres et est-ce que le traitement des lignes doit être séquentiel (ou pas) ?

fait plusieurs requêtes (select) dans la bdd.

As-tu éventuellement pensé avec une procédure stockée qui ferait le traitement complet d'une ligne ?

[rami25316]

Les traitements sur les lignes ne peuvent pas être fait de manière séparer et est fait séquentiellement.

Je n'avais pas penser aux procédures stockées. Mais je n'est pas accès à la bdd. J'ai en charge le code source de l'application donc mon champs d'action est assez limité

[plawyx]

Les traitements sur les lignes ne peuvent pas être fait de manière séparer et est fait séquentiellement.

Est-ce que chaque ligne peut-être traitées indépendamment les unes des autres ?

[rami25316]

Chaque ligne peut être traité indépendamment. Cependant le fichier excel doit être traité dans sa totalité d'une traite.

Ps :Merci de ton aide.

[plawyx]

Chaque ligne peut être traité indépendamment. Cependant le fichier excel doit être traité dans sa totalité d'une traite.

Ps :Merci de ton aide.

Dans ce cas, as-tu utilisé des Callable et Future pour paralléliser le traitement ton fichier exel. Grâce à l'indépendance de chaque ligne, tu gagneras sûrement en temps de traitement. Comme tu utilises jdk 1.5, jette un oeil sur le lien ci-dessous:


http://docs.oracle.com/javase/1.5.0/...nt/Future.html

[tchize_]

Bonjour,
mon application charge un fichier Excel de 37124 lignes et pour chacune de ces lignes, fait plusieurs requêtes (select) dans la bdd.
Mon problème est qu'au bout de plusieurs minutes (prés d'une heure) de traitement le navigateur m'affiche:

Désolé, mais à part avec un problème de design, il n'y a pas de raison que le traitement de 37.000 ligne mette une heure. On est à 100ms de traitement par ligne de fichier, c'est catastrophique en 2014.

Faudrait nous expliquer ce que tu fais, il doit y avoir moyen de regrouper ces traitements.

[rami25316]

Désolé, mais à part avec un problème de design, il n'y a pas de raison que le traitement de 37.000 ligne mette une heure. On est à 100ms de traitement par ligne de fichier, c'est catastrophique en 2014.

Faudrait nous expliquer ce que tu fais, il doit y avoir moyen de regrouper ces traitements.

J'ai vraiment simplifié le travail de l'application. Je fais beaucoup de testes avant l'envoi à la bdd ca explique la longueur du traitement?

Dans ce cas, as-tu utilisé des Callable et Future pour paralléliser le traitement ton fichier exel. Grâce à l'indépendance de chaque ligne, tu gagneras sûrement en temps de traitement. Comme tu utilises jdk 1.5, jette un oeil sur le lien ci-dessous:


http://docs.oracle.com/javase/1.5.0/...nt/Future.html

Je ne suis pas très au faite de ce dont tu parle. Je vais regarder ca.

Merci

[Tonyo38]

J'ai vraiment simplifié le travail de l'application. Je fais beaucoup de testes avant l'envoi à la bdd ca explique la longueur du traitement?

Si à chaque ligne tu ajoutes plusieurs tests effectivement ça explique la longueur du traitement.

J'ai une idée, vous me direz si elle est viable : Utiliser des Thread pour qu'à chaque ligne on appel un Thread qui va faire les tests et l'envoie en bdd

[rami25316]

Si à chaque ligne tu ajoute plusieurs tests effectivement ça explique la longueur du traitement.

J'ai une idée, vous me direz si elle est viable : Utiliser des Thread pour qu'à chaque ligne on appel un Thread qui va faire les tests et l'envoie en bdd

L'application utilise déjà des Threads. Je continue à regarder ce dont m'a parlé plawyx.

Si je trouve la solution je la partagerai ici.


Merci pour votre aide.

[DevServlet]

Bonjour,

Je rejoins les autres, les temps de traitements sont effets trop longs. Est-il possible d’accéder par lots de 1000 par exemple à la BDD, au lieu de 37000 aller/retour, tu ferais plutôt 37 aller/retour? il est bien connu que les accès base sont très coûteux.

[KpTn]

Sans plus d'informations sur ce que fait exactement le traitement d'une ligne ça va être compliqué de t'aider.

Néanmoins comment fais tu tes accès à la base de données ? En JDBC ? Avec un framework de mapping ORM ?

Au delà du fait de paralléliser le traitement il vaut mieux comment par réfléchir à l'algorithme en lui meme. En effet les gains sont souvent bien plus importants en modélisant correctement qu'en comptant sur la puissance de ma machine et a sa capacité de parallélisation.

[rami25316]

Sans plus d'informations sur ce que fait exactement le traitement d'une ligne ça va être compliqué de t'aider.

Néanmoins comment fais tu tes accès à la base de données ? En JDBC ? Avec un framework de mapping ORM ?

Au delà du fait de paralléliser le traitement il vaut mieux comment par réfléchir à l'algorithme en lui meme. En effet les gains sont souvent bien plus importants en modélisant correctement qu'en comptant sur la puissance de ma machine et a sa capacité de parallélisation.

Bonjour,

Je rejoins les autres, les temps de traitements sont effets trop longs. Est-il possible d’accéder par lots de 1000 par exemple à la BDD, au lieu de 37000 aller/retour, tu ferais plutôt 37 aller/retour? il est bien connu que les accès base sont très coûteux.

Pour les accès à la BDD j'utilise hibernate.
Je suis d'accord avec vous le temps de traitement est très long et l'algorithme de l'application pourrait être optimisé cependant l'application est déjà développée.
J'ai en charge sa maintenance, je ne peux donc pas tous modifier à ma guise ni vous faire part des traitements effectués par l'application.

J'essai de voire toute les possibilités avant de faire un rapport à mes chefs. Votre aide m'est d'une grande utilité. Merci

[tchize_]

toutes les solutions amènerons inévitablement une modification de l'application.

Soit tu revois les algos
Soit tu poste tes algos et on te dit ce qui cloche.
Tu peux aussi mettre ça en tâche de fond et créer un page de progression -> faut revoir complètement l'ui
Hibenate dispose aussi d'un traitement par batch, mais ça concerne plus les importation massive de centaines de milliers de lignes

Avec du hibernate, ça pue le "pour chaque ligne on fait une nouvelle session hibernate qui charge la moitié de la database car on a fait ça comme un cochon"