Subject: Re: Re : Problème de propagation dans mes transactions + Charge de tomcat - msg#00046

Previous Message by Date: click to view message preview

Re: Re : Problème de propagation dans mes transactions + Charge de tomcat

Salut  Ne serait-il pas plus efficace de laisser la base de données gérer le "lock" toute seule avec une transaction configurée en SERIALIZABLE ?Je ne vois pas bien là. J'ai une transaction métier longue, et une mise à jour sur une table technique à forte concurrence d'accès. Si je mets ma transaction métier en SERIALIZABLE, je vais complètement écrouler mes perfs : je ne pourrais avoir deux transactions métier qui accèdent à cette table s'exécuter en même temps. Je suis dans un cas qui ressemble beaucoup à de la génération d'ID telle que peut le faire hibernate avec du HILO. D'ailleurs, l'utilisation d'un mécanisme de génération HILO avec hibernate pose le même problème que mon REQUIRES_NEW. > En pratique, Tomcat est largement >> capable de supporter une charge de 300 utilisateurs simultanés Je confirme, mais :  - quelle version de Tomcat ?  - quel serveur physique ?  - quel OS ?Je suis avec Tomcat 5.5, windows 2003 server, sur une plateforme intel 64 bits octo coeur. J'ai bien vu l'alternative nio mais j'aurais aimé tester APR avec tomcat 5.5 avant de passer à tomcat 6.0. En dehors de cela, savez vous si je pourrais avoir des différences significatives en passant de tomcat 5.5 à tomcat 6.0 ? Pour les APR, j'ai un probème de prise en compte sur ma plateforme (qu'elle que soit la dll 64 bits utilisée, tomcat me dit qu'il ne trouve pas APR) : quelqu'un a déjà eu ce problème ? Y a t'il une solution autre que recompiler la dll sur la plateforme cible ? Merci Seb Si tu es sous Tomcat 6, il y a le protocole org.apache.coyote.http11.Http11NioProtocol comme alternative à APR http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Connector%20Comparison Damien

Next Message by Date: click to view message preview

Re: Re : Problème de propagation dans mes transactions + Charge de tomcat

Oui oui, nous avons pas loin de 1000 instances de tomcat qui tournent chez le client :-)Sinon oui je sais il y a Terracota, JBossCache et même EHCache que nous utilisons avec Hibernate. Il suffit de remplacer nos bonnes vieilles map par ces caches, mais pour l'instant c'est du domaine du yakafocon. En plus on a d'autres problématiques métier en plus des caches. Nous utilisons un intercepteur hibernate pour détecter les modifications effectuées et invalider les caches en conséquence. Quid du fonctionnement en mode distribué ? Nous ne sommes pas complètement sûr du bon fonctionnement de notre appli en mode distribué. En plus pour l'instant on est de l'ordre de 500 connexions simultanées. Faut il vraiment faire du load balancing dans ce cas ? Je ne suis pas sûr. Avec l'augmentation de la mémoire disponible et du nombre de coeur sur un serveur. On peut sans doute s'en sortir sans ça. Seb2008/5/29 Olivier Lamy <olamy@xxxxxxxxxx>: Le 29 mai 2008 11:25, Sebastien Cesbron <scesbron@xxxxxxxxx> a écrit : >> Sinon question bête pourquoi ne fais tu pas du load balancing avec un >> frontal web devant (httpd par exemple avec le connecteur vers tomcat) > > Merci pour le lien > > La question n'est pas bête, la réponse l'est peut être : > 1 - Il n'y a qu'un seul cas d'utilisation qui amène cette charge et vu que > c'est pour un progiciel installé chez n clients, plus on simplifie > l'installation mieux c'est Tu veux dire le tomcat tourne chez le client ? > 2 - Nous avons des gestions de cache "maison" dans l'appli qui ne > fonctionnent pas forcément très bien en mode distribué regarde http://www.terracotta.org/ c'est vraiment pas mal > > >

Previous Message by Thread: click to view message preview

Re: Re : Problème de propagation dans mes transactions + Charge de tomcat

Salut  Ne serait-il pas plus efficace de laisser la base de données gérer le "lock" toute seule avec une transaction configurée en SERIALIZABLE ?Je ne vois pas bien là. J'ai une transaction métier longue, et une mise à jour sur une table technique à forte concurrence d'accès. Si je mets ma transaction métier en SERIALIZABLE, je vais complètement écrouler mes perfs : je ne pourrais avoir deux transactions métier qui accèdent à cette table s'exécuter en même temps. Je suis dans un cas qui ressemble beaucoup à de la génération d'ID telle que peut le faire hibernate avec du HILO. D'ailleurs, l'utilisation d'un mécanisme de génération HILO avec hibernate pose le même problème que mon REQUIRES_NEW. > En pratique, Tomcat est largement >> capable de supporter une charge de 300 utilisateurs simultanés Je confirme, mais :  - quelle version de Tomcat ?  - quel serveur physique ?  - quel OS ?Je suis avec Tomcat 5.5, windows 2003 server, sur une plateforme intel 64 bits octo coeur. J'ai bien vu l'alternative nio mais j'aurais aimé tester APR avec tomcat 5.5 avant de passer à tomcat 6.0. En dehors de cela, savez vous si je pourrais avoir des différences significatives en passant de tomcat 5.5 à tomcat 6.0 ? Pour les APR, j'ai un probème de prise en compte sur ma plateforme (qu'elle que soit la dll 64 bits utilisée, tomcat me dit qu'il ne trouve pas APR) : quelqu'un a déjà eu ce problème ? Y a t'il une solution autre que recompiler la dll sur la plateforme cible ? Merci Seb Si tu es sous Tomcat 6, il y a le protocole org.apache.coyote.http11.Http11NioProtocol comme alternative à APR http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Connector%20Comparison Damien

Next Message by Thread: click to view message preview

Re: Re : Problème de propagation dans mes transactions + Charge de tomcat

Oui oui, nous avons pas loin de 1000 instances de tomcat qui tournent chez le client :-)Sinon oui je sais il y a Terracota, JBossCache et même EHCache que nous utilisons avec Hibernate. Il suffit de remplacer nos bonnes vieilles map par ces caches, mais pour l'instant c'est du domaine du yakafocon. En plus on a d'autres problématiques métier en plus des caches. Nous utilisons un intercepteur hibernate pour détecter les modifications effectuées et invalider les caches en conséquence. Quid du fonctionnement en mode distribué ? Nous ne sommes pas complètement sûr du bon fonctionnement de notre appli en mode distribué. En plus pour l'instant on est de l'ordre de 500 connexions simultanées. Faut il vraiment faire du load balancing dans ce cas ? Je ne suis pas sûr. Avec l'augmentation de la mémoire disponible et du nombre de coeur sur un serveur. On peut sans doute s'en sortir sans ça. Seb2008/5/29 Olivier Lamy <olamy@xxxxxxxxxx>: Le 29 mai 2008 11:25, Sebastien Cesbron <scesbron@xxxxxxxxx> a écrit : >> Sinon question bête pourquoi ne fais tu pas du load balancing avec un >> frontal web devant (httpd par exemple avec le connecteur vers tomcat) > > Merci pour le lien > > La question n'est pas bête, la réponse l'est peut être : > 1 - Il n'y a qu'un seul cas d'utilisation qui amène cette charge et vu que > c'est pour un progiciel installé chez n clients, plus on simplifie > l'installation mieux c'est Tu veux dire le tomcat tourne chez le client ? > 2 - Nous avons des gestions de cache "maison" dans l'appli qui ne > fonctionnent pas forcément très bien en mode distribué regarde http://www.terracotta.org/ c'est vraiment pas mal > > >