De mémoire, HP-UX n'est pas forcement la meilleur archi pour
faire tourner du Java.
<mode_troll>
Je ne vois qu'une solution pour faire tourner toute ton
usine (WebSphere, hibernate, etc etc) c'est d'installer
un E10K ou E15K.
En faisant ce qu'il faut pour avoir assez de mémoire
et assez de noeuds CPU, a mon avis tu devrais retrouver
des perfs correctes.
Ou encore monter un cluster de 8 Bi Xeon ....
J'arrete la ca ira ;)
</mode_troll>
en bref, bonne chance :)
De mémoire, HP-UX n'est pas forcement la meilleur archi pour
faire tourner du Java.
<mode_troll>
Je ne vois qu'une solution pour faire tourner toute ton
usine (WebSphere, hibernate, etc etc) c'est d'installer
un E10K ou E15K.
En faisant ce qu'il faut pour avoir assez de mémoire
et assez de noeuds CPU, a mon avis tu devrais retrouver
des perfs correctes.
Ou encore monter un cluster de 8 Bi Xeon ....
J'arrete la ca ira ;)
</mode_troll>
en bref, bonne chance :)
De mémoire, HP-UX n'est pas forcement la meilleur archi pour
faire tourner du Java.
<mode_troll>
Je ne vois qu'une solution pour faire tourner toute ton
usine (WebSphere, hibernate, etc etc) c'est d'installer
un E10K ou E15K.
En faisant ce qu'il faut pour avoir assez de mémoire
et assez de noeuds CPU, a mon avis tu devrais retrouver
des perfs correctes.
Ou encore monter un cluster de 8 Bi Xeon ....
J'arrete la ca ira ;)
</mode_troll>
en bref, bonne chance :)
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Alors le choix d'hibernate n'est pas adapté à ton problème.
Mauvais outil changer d'outil.
Non. Tout le reste de l'appli fonctionne à merveille.
Plus encore mauvaise méthode changer de méthode.
Dans tous les cas, cela ne fera que repousser l'échéance.
J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes.
Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant
d'une requête à l'autre, genre ta session
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)
Va savoir ce que font les autres :-)
Si tu avais la main sur la requête tu peux ne charger que 30 lignes à
la fois mais je ne suis pas sûr qu'Hibernate sache faire...
Oui. C'est la piste que je comptais étudier.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et
10 fois plus performant.
Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que
tu intègre (hibernate)).
Alors comment expliques tu que la meme requete avec plusieurs utilisateurs
Sans vouloir paraître dur avec toi,
c'est gentil de t'inquiéter pour moi :-)
si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement
monothreadé,
Moins performant je m'y attendais, mais que l'écart soit aussi énorme, je
je pense qu'il y a beaucoup de pièges pires dans lequel
tu tomberais avec un cluster
t'en fais pas, j'apprends vite.
Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de
payer un unix cher, c'est peut-être autre chose... Je ne connais pas
ton client, mais un serveur unix ça a du hard redondant, ça sait
faire du scale-up (pour une base de données par exemple dans beaucoup
de cas (pas tous) les cluster et les trucs distribués c'est du pipo
marketing ça ne marche pas ou bcp moins bien)), c'est intégré
correctement dans les process et avec les produits faits pour faire
de la haute-dispo et du plan de secours (SAN, etc.).
Peut etre. Ceci dit quand une carte réseau tombe en panne, j'ai plus de
Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion.
Sur le meme serveur il y a une appli de cartes de voeux. Je pense que la
Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Et pas uniquement celui de HP...
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Alors le choix d'hibernate n'est pas adapté à ton problème.
Mauvais outil changer d'outil.
Non. Tout le reste de l'appli fonctionne à merveille.
Plus encore mauvaise méthode changer de méthode.
Dans tous les cas, cela ne fera que repousser l'échéance.
J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes.
Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant
d'une requête à l'autre, genre ta session
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)
Va savoir ce que font les autres :-)
Si tu avais la main sur la requête tu peux ne charger que 30 lignes à
la fois mais je ne suis pas sûr qu'Hibernate sache faire...
Oui. C'est la piste que je comptais étudier.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et
10 fois plus performant.
Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que
tu intègre (hibernate)).
Alors comment expliques tu que la meme requete avec plusieurs utilisateurs
Sans vouloir paraître dur avec toi,
c'est gentil de t'inquiéter pour moi :-)
si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement
monothreadé,
Moins performant je m'y attendais, mais que l'écart soit aussi énorme, je
je pense qu'il y a beaucoup de pièges pires dans lequel
tu tomberais avec un cluster
t'en fais pas, j'apprends vite.
Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de
payer un unix cher, c'est peut-être autre chose... Je ne connais pas
ton client, mais un serveur unix ça a du hard redondant, ça sait
faire du scale-up (pour une base de données par exemple dans beaucoup
de cas (pas tous) les cluster et les trucs distribués c'est du pipo
marketing ça ne marche pas ou bcp moins bien)), c'est intégré
correctement dans les process et avec les produits faits pour faire
de la haute-dispo et du plan de secours (SAN, etc.).
Peut etre. Ceci dit quand une carte réseau tombe en panne, j'ai plus de
Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion.
Sur le meme serveur il y a une appli de cartes de voeux. Je pense que la
Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Et pas uniquement celui de HP...
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Alors le choix d'hibernate n'est pas adapté à ton problème.
Mauvais outil changer d'outil.
Non. Tout le reste de l'appli fonctionne à merveille.
Plus encore mauvaise méthode changer de méthode.
Dans tous les cas, cela ne fera que repousser l'échéance.
J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes.
Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant
d'une requête à l'autre, genre ta session
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)
Va savoir ce que font les autres :-)
Si tu avais la main sur la requête tu peux ne charger que 30 lignes à
la fois mais je ne suis pas sûr qu'Hibernate sache faire...
Oui. C'est la piste que je comptais étudier.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et
10 fois plus performant.
Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que
tu intègre (hibernate)).
Alors comment expliques tu que la meme requete avec plusieurs utilisateurs
Sans vouloir paraître dur avec toi,
c'est gentil de t'inquiéter pour moi :-)
si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement
monothreadé,
Moins performant je m'y attendais, mais que l'écart soit aussi énorme, je
je pense qu'il y a beaucoup de pièges pires dans lequel
tu tomberais avec un cluster
t'en fais pas, j'apprends vite.
Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de
payer un unix cher, c'est peut-être autre chose... Je ne connais pas
ton client, mais un serveur unix ça a du hard redondant, ça sait
faire du scale-up (pour une base de données par exemple dans beaucoup
de cas (pas tous) les cluster et les trucs distribués c'est du pipo
marketing ça ne marche pas ou bcp moins bien)), c'est intégré
correctement dans les process et avec les produits faits pour faire
de la haute-dispo et du plan de secours (SAN, etc.).
Peut etre. Ceci dit quand une carte réseau tombe en panne, j'ai plus de
Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion.
Sur le meme serveur il y a une appli de cartes de voeux. Je pense que la
Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Et pas uniquement celui de HP...
Derek Sagan wrote:Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Alors le choix d'hibernate n'est pas adapté à ton problème.
Hibernate est bien adapté jusqu'à 2000 lignes (1 seconde)
A partir de 4000 ca commence à etre long (5 secondes chez moi)
6000 lignes c'est catastrophique, 10 secondes.
Multiplier les temps par 5-6 pour afficher la meme page depuis le serveur HP
(en comptant le transfert réseau adsl).Mauvais outil changer d'outil.
Non. Tout le reste de l'appli fonctionne à merveille.
Seul le moteur de recherche souffre quand on lui demande d'extraire tout le
contenu de la base.
Plus encore mauvaise méthode changer de méthode.
Dans tous les cas, cela ne fera que repousser l'échéance.
Je trouve absurde de remonter une telle quantité de données.J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes.
Non. Il recherche 6000 lignes, je lui en affiche 50 page page.
La pagination est gérée par struts-layout.
Je suppose qu'il la pose en session. C'est ce que je vérifie en ce moment,
mais je vois pas comment il ferait autrement.
Ceci dit une grande partie de la ligne est lazy loaded, donc chargée
uniquement lorsqu'elle est affichée.
Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant
d'une requête à l'autre, genre ta session
Y a des chances :-)
Ceci dit je n'ai pas trop de problèmes de mémoire sur mon poste, meme avec
plusieurs utilisateurs.
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)
Va savoir ce que font les autres :-)
Si tu avais la main sur la requête tu peux ne charger que 30 lignes à
la fois mais je ne suis pas sûr qu'Hibernate sache faire...
Oui. C'est la piste que je comptais étudier.
Une autre solution serait de définir un 2e mapping qui remonterait un peu
moins de colonnes.
(Mais je pense qu'elles sont toutes nécessaires.)Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et
10 fois plus performant.
Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que
tu intègre (hibernate)).
Alors comment expliques tu que la meme requete avec plusieurs utilisateurs
simultanés chez moi ne pose pas spécialement de probleme ?
(4-5 secondes).
Il y a quand meme probablement un problème sur ce serveur.
Sans vouloir paraître dur avec toi,
c'est gentil de t'inquiéter pour moi :-)si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement
monothreadé,
Moins performant je m'y attendais, mais que l'écart soit aussi énorme, je
m'y attendais moins.je pense qu'il y a beaucoup de pièges pires dans lequel
tu tomberais avec un cluster
t'en fais pas, j'apprends vite.Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de
payer un unix cher, c'est peut-être autre chose... Je ne connais pas
ton client, mais un serveur unix ça a du hard redondant, ça sait
faire du scale-up (pour une base de données par exemple dans beaucoup
de cas (pas tous) les cluster et les trucs distribués c'est du pipo
marketing ça ne marche pas ou bcp moins bien)), c'est intégré
correctement dans les process et avec les produits faits pour faire
de la haute-dispo et du plan de secours (SAN, etc.).
Peut etre. Ceci dit quand une carte réseau tombe en panne, j'ai plus de
serveur pendant 1 journée complète.
alors la haute dispo et le plan de secours ca me fait bien rire.
Tout comme les autres appli avec lesquelle mon appli communique, qui
s'écroulent lamentablement alors qu'elles sont plus critiques que la mienne.
Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion.
Sur le meme serveur il y a une appli de cartes de voeux. Je pense que la
mienne a besoin d'une dispo un peu plus haute :-)
Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Et pas uniquement celui de HP...
Merci pour les conseils.
Derek Sagan wrote:
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Alors le choix d'hibernate n'est pas adapté à ton problème.
Hibernate est bien adapté jusqu'à 2000 lignes (1 seconde)
A partir de 4000 ca commence à etre long (5 secondes chez moi)
6000 lignes c'est catastrophique, 10 secondes.
Multiplier les temps par 5-6 pour afficher la meme page depuis le serveur HP
(en comptant le transfert réseau adsl).
Mauvais outil changer d'outil.
Non. Tout le reste de l'appli fonctionne à merveille.
Seul le moteur de recherche souffre quand on lui demande d'extraire tout le
contenu de la base.
Plus encore mauvaise méthode changer de méthode.
Dans tous les cas, cela ne fera que repousser l'échéance.
Je trouve absurde de remonter une telle quantité de données.
J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes.
Non. Il recherche 6000 lignes, je lui en affiche 50 page page.
La pagination est gérée par struts-layout.
Je suppose qu'il la pose en session. C'est ce que je vérifie en ce moment,
mais je vois pas comment il ferait autrement.
Ceci dit une grande partie de la ligne est lazy loaded, donc chargée
uniquement lorsqu'elle est affichée.
Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant
d'une requête à l'autre, genre ta session
Y a des chances :-)
Ceci dit je n'ai pas trop de problèmes de mémoire sur mon poste, meme avec
plusieurs utilisateurs.
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)
Va savoir ce que font les autres :-)
Si tu avais la main sur la requête tu peux ne charger que 30 lignes à
la fois mais je ne suis pas sûr qu'Hibernate sache faire...
Oui. C'est la piste que je comptais étudier.
Une autre solution serait de définir un 2e mapping qui remonterait un peu
moins de colonnes.
(Mais je pense qu'elles sont toutes nécessaires.)
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et
10 fois plus performant.
Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que
tu intègre (hibernate)).
Alors comment expliques tu que la meme requete avec plusieurs utilisateurs
simultanés chez moi ne pose pas spécialement de probleme ?
(4-5 secondes).
Il y a quand meme probablement un problème sur ce serveur.
Sans vouloir paraître dur avec toi,
c'est gentil de t'inquiéter pour moi :-)
si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement
monothreadé,
Moins performant je m'y attendais, mais que l'écart soit aussi énorme, je
m'y attendais moins.
je pense qu'il y a beaucoup de pièges pires dans lequel
tu tomberais avec un cluster
t'en fais pas, j'apprends vite.
Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de
payer un unix cher, c'est peut-être autre chose... Je ne connais pas
ton client, mais un serveur unix ça a du hard redondant, ça sait
faire du scale-up (pour une base de données par exemple dans beaucoup
de cas (pas tous) les cluster et les trucs distribués c'est du pipo
marketing ça ne marche pas ou bcp moins bien)), c'est intégré
correctement dans les process et avec les produits faits pour faire
de la haute-dispo et du plan de secours (SAN, etc.).
Peut etre. Ceci dit quand une carte réseau tombe en panne, j'ai plus de
serveur pendant 1 journée complète.
alors la haute dispo et le plan de secours ca me fait bien rire.
Tout comme les autres appli avec lesquelle mon appli communique, qui
s'écroulent lamentablement alors qu'elles sont plus critiques que la mienne.
Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion.
Sur le meme serveur il y a une appli de cartes de voeux. Je pense que la
mienne a besoin d'une dispo un peu plus haute :-)
Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Et pas uniquement celui de HP...
Merci pour les conseils.
Derek Sagan wrote:Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Alors le choix d'hibernate n'est pas adapté à ton problème.
Hibernate est bien adapté jusqu'à 2000 lignes (1 seconde)
A partir de 4000 ca commence à etre long (5 secondes chez moi)
6000 lignes c'est catastrophique, 10 secondes.
Multiplier les temps par 5-6 pour afficher la meme page depuis le serveur HP
(en comptant le transfert réseau adsl).Mauvais outil changer d'outil.
Non. Tout le reste de l'appli fonctionne à merveille.
Seul le moteur de recherche souffre quand on lui demande d'extraire tout le
contenu de la base.
Plus encore mauvaise méthode changer de méthode.
Dans tous les cas, cela ne fera que repousser l'échéance.
Je trouve absurde de remonter une telle quantité de données.J'espère que tu ne veux pas dire qu'à chaque fois que l'utilisateur
charge une page de 30 lignes hibernate charge 6000 lignes.
Non. Il recherche 6000 lignes, je lui en affiche 50 page page.
La pagination est gérée par struts-layout.
Je suppose qu'il la pose en session. C'est ce que je vérifie en ce moment,
mais je vois pas comment il ferait autrement.
Ceci dit une grande partie de la ligne est lazy loaded, donc chargée
uniquement lorsqu'elle est affichée.
Ni que tu
garde les 6000 lignes une fois pour toute dans un objet persistant
d'une requête à l'autre, genre ta session
Y a des chances :-)
Ceci dit je n'ai pas trop de problèmes de mémoire sur mon poste, meme avec
plusieurs utilisateurs.
Faire ça sur un serveur mutualisé ca devrait être passible de la cour
martiale. ;-)
Va savoir ce que font les autres :-)
Si tu avais la main sur la requête tu peux ne charger que 30 lignes à
la fois mais je ne suis pas sûr qu'Hibernate sache faire...
Oui. C'est la piste que je comptais étudier.
Une autre solution serait de définir un 2e mapping qui remonterait un peu
moins de colonnes.
(Mais je pense qu'elles sont toutes nécessaires.)Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et
10 fois plus performant.
Ce qui n'aurai pas résolu tes problèmes de performance qui n'ont rien
avoir avec le hard mais avec ton soft (celui que tu fais et celui que
tu intègre (hibernate)).
Alors comment expliques tu que la meme requete avec plusieurs utilisateurs
simultanés chez moi ne pose pas spécialement de probleme ?
(4-5 secondes).
Il y a quand meme probablement un problème sur ce serveur.
Sans vouloir paraître dur avec toi,
c'est gentil de t'inquiéter pour moi :-)si tu ne sais pas que ton unix est
moins performant que ton poste de travail sur un traitement
monothreadé,
Moins performant je m'y attendais, mais que l'écart soit aussi énorme, je
m'y attendais moins.je pense qu'il y a beaucoup de pièges pires dans lequel
tu tomberais avec un cluster
t'en fais pas, j'apprends vite.Au fait si ce n'est pas la puissance CPU pure qui vaut le coup de
payer un unix cher, c'est peut-être autre chose... Je ne connais pas
ton client, mais un serveur unix ça a du hard redondant, ça sait
faire du scale-up (pour une base de données par exemple dans beaucoup
de cas (pas tous) les cluster et les trucs distribués c'est du pipo
marketing ça ne marche pas ou bcp moins bien)), c'est intégré
correctement dans les process et avec les produits faits pour faire
de la haute-dispo et du plan de secours (SAN, etc.).
Peut etre. Ceci dit quand une carte réseau tombe en panne, j'ai plus de
serveur pendant 1 journée complète.
alors la haute dispo et le plan de secours ca me fait bien rire.
Tout comme les autres appli avec lesquelle mon appli communique, qui
s'écroulent lamentablement alors qu'elles sont plus critiques que la mienne.
Mais peut-être que je me trompe. Que ton client n'a pas de besoin de
haute dispo, ni de plan de secours en cas d'incendie/dégâts des
eaux/chute d'avion.
Sur le meme serveur il y a une appli de cartes de voeux. Je pense que la
mienne a besoin d'une dispo un peu plus haute :-)
Peut-être juste que le commercial d'HP a les dents
blanches, auquel cas je comprends ta réaction.
Et pas uniquement celui de HP...
Merci pour les conseils.
Derek Sagan wrote:Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernateParce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plustorche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10 fois
plus performant.Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu
Merci.
Ne connaissant pas votre niveau de connaissance sur Hibernate,
Derek Sagan wrote:
Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Parce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.
Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plus
torche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.
A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.
poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10 fois
plus performant.
Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.
Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu
Merci.
Ne connaissant pas votre niveau de connaissance sur Hibernate,
Derek Sagan wrote:Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un seul
coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernateParce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plustorche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10 fois
plus performant.Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu
Merci.
Ne connaissant pas votre niveau de connaissance sur Hibernate,
Derek Sagan wrote:Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un
seul coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernateParce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plustorche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10
fois plus performant.Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu
Merci.
Ne connaissant pas votre niveau de connaissance sur Hibernate,
ci-dessous quelques points notés sur une première expérience Hibernate.
Avec Hibernate, ( et autres ORM certainement), il faut faire trés
attention à la gestion des sessions : session longue ou plusieurs
session courtes ; Dans le second cas on n'optimise pas l'utilisation du
cache hibernate au maximun.
Jouer aussi avec les paramétres de chargement ( leazy ) pour tuner.
Le parametre sql_show à true permet de voir d'une part le code généré et
les acces bases.
Pour ma part je trouve que Hibernate est un tres bon produit.
Derek Sagan wrote:
Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un
seul coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernate
Parce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.
Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plus
torche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.
A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.
poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10
fois plus performant.
Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.
Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu
Merci.
Ne connaissant pas votre niveau de connaissance sur Hibernate,
ci-dessous quelques points notés sur une première expérience Hibernate.
Avec Hibernate, ( et autres ORM certainement), il faut faire trés
attention à la gestion des sessions : session longue ou plusieurs
session courtes ; Dans le second cas on n'optimise pas l'utilisation du
cache hibernate au maximun.
Jouer aussi avec les paramétres de chargement ( leazy ) pour tuner.
Le parametre sql_show à true permet de voir d'une part le code généré et
les acces bases.
Pour ma part je trouve que Hibernate est un tres bon produit.
Derek Sagan wrote:Cela dit très respectueusement, c'est complètement irresponsable de
ramener autant d'objets, pour peu qu'ils soient bien gras c'est
sûrement là que sont tes 80 Mo.
Je suis bien d'accord. Je sais d'ou viennent mes 80Mo.
Mais les utilisateurs veulent pouvoir remonter 1 mois de données d'un
seul coup.
Ce qui me donne un tableau de 6000 lignes sur 30 colonnes.
Certes paginé, mais tout de meme chargé en mémoire par hibernateParce qu'un CPU de ton serveur est environe 2 fois moins rapide à
parcourir un iterateur que celui de ton poste de travail.
Très probable.Sur le papier dont tu parles ton pa-risc ou ton itanium (je sais pas
ce que c'est ton hpux risc)
moi non plustorche un PC parce qu'il est testé avec
une application consommatrice d'I/O (ce en quoi le PC est mauvais et
un serveur unix bon) et surtout multithreadé donc capable d'utiliser
plusieurs CPU en même temps.
un CPU intel torche n'importe quel cpu 64 bits riscs avec
turbo-compresseur à induction nucléaire.
Bien vu.A vue de nez je dirais que tu as un pentium entre 1.5GHz et 2GHz comme
PIV 3GHz.poste de travail, ça doit être à peu près le ratio pour faire fois 2
avec ton 64 bits 750 MHz
Désolé d'égratigner un mythe, ce n'est pas pour sa puissance CPU pure
(un CPU à la fois) que ta boîte paye si cher HP.
Pas ma boite. Mon client.
Perso j'aurais fait un bon gros cluster pour 10 fois moins cher et 10
fois plus performant.Ou bien
quelqu'un d'autre utilise le serveur en même temps que toi et le
sature.
Va savoir, il y a plus de 20 autres applis sur ce serveur.Mais de loin le plus probable c'est ce que je dis ci-dessus.
Tu m'as convaincu
Merci.
Ne connaissant pas votre niveau de connaissance sur Hibernate,
ci-dessous quelques points notés sur une première expérience Hibernate.
Avec Hibernate, ( et autres ORM certainement), il faut faire trés
attention à la gestion des sessions : session longue ou plusieurs
session courtes ; Dans le second cas on n'optimise pas l'utilisation du
cache hibernate au maximun.
Jouer aussi avec les paramétres de chargement ( leazy ) pour tuner.
Le parametre sql_show à true permet de voir d'une part le code généré et
les acces bases.
Pour ma part je trouve que Hibernate est un tres bon produit.
. Avec Hibernate, ( et autres ORM certainement), il faut
faire trés attention à la gestion des sessions : session longue ou
plusieurs session courtes ; Dans le second cas on n'optimise pas
l'utilisation du cache hibernate au maximun.
Jouer aussi avec les paramétres de chargement ( leazy ) pour tuner.
Le parametre sql_show à true permet de voir d'une part le code généré
et les acces bases.
Qui est très propre dans mon cas.
Pour ma part je trouve que Hibernate est un tres bon produit.
Idem.
. Avec Hibernate, ( et autres ORM certainement), il faut
faire trés attention à la gestion des sessions : session longue ou
plusieurs session courtes ; Dans le second cas on n'optimise pas
l'utilisation du cache hibernate au maximun.
Jouer aussi avec les paramétres de chargement ( leazy ) pour tuner.
Le parametre sql_show à true permet de voir d'une part le code généré
et les acces bases.
Qui est très propre dans mon cas.
Pour ma part je trouve que Hibernate est un tres bon produit.
Idem.
. Avec Hibernate, ( et autres ORM certainement), il faut
faire trés attention à la gestion des sessions : session longue ou
plusieurs session courtes ; Dans le second cas on n'optimise pas
l'utilisation du cache hibernate au maximun.
Jouer aussi avec les paramétres de chargement ( leazy ) pour tuner.
Le parametre sql_show à true permet de voir d'une part le code généré
et les acces bases.
Qui est très propre dans mon cas.
Pour ma part je trouve que Hibernate est un tres bon produit.
Idem.
Mauvais outil pour le module derecherche, change d'outil pour le
module de recherche.
Oui c'est vrai c'est assez économe somme toute les trucs de fainéant
(j'utilise le mot pour "lazy" pas forcément pour toi, pas de
méprise...), ça ne prend que 80 Mo de RAM par utilisateur qui fait une
recherche.
Alors imagine sans les trucs de fénéant lol :-)
C'est pour le bien des autres qu'il faut que tu arrêtes de prendre 80
Mo par requête
La mémoire que je consomme ne sera à priori pas consommée par les autres
De rien, au bout du compte à part te dire (très fort) que ton serveur
va moins vite que ton PC je n'ai pas dis grand chose...
Mauvais outil pour le module derecherche, change d'outil pour le
module de recherche.
Oui c'est vrai c'est assez économe somme toute les trucs de fainéant
(j'utilise le mot pour "lazy" pas forcément pour toi, pas de
méprise...), ça ne prend que 80 Mo de RAM par utilisateur qui fait une
recherche.
Alors imagine sans les trucs de fénéant lol :-)
C'est pour le bien des autres qu'il faut que tu arrêtes de prendre 80
Mo par requête
La mémoire que je consomme ne sera à priori pas consommée par les autres
De rien, au bout du compte à part te dire (très fort) que ton serveur
va moins vite que ton PC je n'ai pas dis grand chose...
Mauvais outil pour le module derecherche, change d'outil pour le
module de recherche.
Oui c'est vrai c'est assez économe somme toute les trucs de fainéant
(j'utilise le mot pour "lazy" pas forcément pour toi, pas de
méprise...), ça ne prend que 80 Mo de RAM par utilisateur qui fait une
recherche.
Alors imagine sans les trucs de fénéant lol :-)
C'est pour le bien des autres qu'il faut que tu arrêtes de prendre 80
Mo par requête
La mémoire que je consomme ne sera à priori pas consommée par les autres
De rien, au bout du compte à part te dire (très fort) que ton serveur
va moins vite que ton PC je n'ai pas dis grand chose...
L'autre solution serait de ne remonter que les valeurs des colonnes choisies
par l'utilisateur (il a une liste de colonnes dans lesquelles il peut
piocher ce qu'il veut), ce qui sera probablement le plus efficace, mais qui
me demandera le plus de travail :-)
[SNIP]
L'autre solution serait de ne remonter que les valeurs des colonnes choisies
par l'utilisateur (il a une liste de colonnes dans lesquelles il peut
piocher ce qu'il veut), ce qui sera probablement le plus efficace, mais qui
me demandera le plus de travail :-)
[SNIP]
L'autre solution serait de ne remonter que les valeurs des colonnes choisies
par l'utilisateur (il a une liste de colonnes dans lesquelles il peut
piocher ce qu'il veut), ce qui sera probablement le plus efficace, mais qui
me demandera le plus de travail :-)
[SNIP]
[SNIP]L'autre solution serait de ne remonter que les valeurs des colonnes
choisies par l'utilisateur (il a une liste de colonnes dans
lesquelles il peut piocher ce qu'il veut), ce qui sera probablement
le plus efficace, mais qui me demandera le plus de travail :-)
[SNIP]
En récupérant la connexion de ta session Hibernate (
session.getConnexion) et en faisant des requetes en sql natif Oracle,
plus facilement customisable ( avec l'objet PreparedStatement) . Mais
là évidemment on détourne un peu le concept O/R .
[SNIP]
L'autre solution serait de ne remonter que les valeurs des colonnes
choisies par l'utilisateur (il a une liste de colonnes dans
lesquelles il peut piocher ce qu'il veut), ce qui sera probablement
le plus efficace, mais qui me demandera le plus de travail :-)
[SNIP]
En récupérant la connexion de ta session Hibernate (
session.getConnexion) et en faisant des requetes en sql natif Oracle,
plus facilement customisable ( avec l'objet PreparedStatement) . Mais
là évidemment on détourne un peu le concept O/R .
[SNIP]L'autre solution serait de ne remonter que les valeurs des colonnes
choisies par l'utilisateur (il a une liste de colonnes dans
lesquelles il peut piocher ce qu'il veut), ce qui sera probablement
le plus efficace, mais qui me demandera le plus de travail :-)
[SNIP]
En récupérant la connexion de ta session Hibernate (
session.getConnexion) et en faisant des requetes en sql natif Oracle,
plus facilement customisable ( avec l'objet PreparedStatement) . Mais
là évidemment on détourne un peu le concept O/R .
