Discussion :

[fxrobin]

"java trop lourd et trop lent"

on peut pas lui en vouloir en même temps, il prêche pour sa paroisse ...

[fxrobin]

Pool de connexion : L'interface DataSource a été intégré dans Java 1.4 (2002)... mais que l'interface, il faut ensuite chercher soit même une implémentation externe comme pooxool ou c3p0 (voir ici ).

euh ... ce qui tu écris n'est pas correct.

Certes DataSource est une interface, mais Tomcat, GlassFish, JBOSS, WebSphere, Resin, Jetty, etc ... proposent une implémentation. Tu n'as donc pas à t'en préoccuper. D'ailleurs tout serveur JEE (light ou complet) doit proposer un pooling JDBC avec DataSource ...

Proxool, C3P0, DBCP, etc. sont effectivement des implémentations qui servent, quand on souhaite absolument "gérer" toi même la connexion JDBC voire même piloter le POOL de manière programmatique ... or en JEE on préfère déléguer l'ensemble au serveur auquel on ne fournit que le Driver JDBC et le moyen de se connecter à la base (url, login, password, paramétrages divers)

[fxrobin]

Multi threading :[/B] Je ne vois pas en quoi créer des threads est utile lorsqu'on fait du développement Web, d'ailleurs créer ses propres threads en JEE est déconseillé (voir ici ou là).

Tu vas penser que je m'acharne, mais ce que tu penses est erronné.
En Web ... tout est multithreadé à commencer par APACHE HTTPD et heureusement, sinon tu ne pourrai servir qu'un seul client à la fois.

Une servlet est aussi MultiThread, il y a même un POOL de Thread dédié.
Idem pour les JSP (car une JSP est une servlet au final)

Quant aux EJB ils sont aussi multithread ... et s'il y a bien un truc de rapide, qui tient la charge (car mécanismes de pré-pooling, serialisation) et évite les débordement de mémoire malgré la tonne de requête à traiter, c'est bien la technologie EJB.

Sinon tu as raison, il ne faut pas créer de Thread dans le traitement d'une requête HTTP, car le serveur d'application doit être l'unique endroit où les Threads doivent être créés. Mais ça n'empêche pas d'avoir des Threads (voir les EJB Timer par exemple).

[alex_vino]

Sinon tu as raison, il ne faut pas créer de Thread dans le traitement d'une requête HTTP, car le serveur d'application doit être l'unique endroit où les Threads doivent être créés. Mais ça n'empêche pas d'avoir des Threads (voir les EJB Timer par exemple).

Dans ce qu'il disait je pense qu'il ne parlait pas de créer un propre serveur HTTP.
Explique pourquoi il ne faut pas créer de thread dans le traitement HTTP

[_skip]

En principe tu ne crées pas de thread directement car c'est une opération assez coûteuse, trop pour le faire à chaque requête. Cela dit ça n'empêche pas que tu puisses créer un pool de thread global à ton application et t'en servir pour certaines tâches asynchrones (requête vers un service externe etc...)

[transgohan]

En principe tu ne crées pas de thread directement car c'est une opération assez coûteuse, trop pour le faire à chaque requête. Cela dit ça n'empêche pas que tu puisses créer un pool de thread global à ton application et t'en servir pour certaines tâches asynchrones (requête vers un service externe etc...)

Pour une requête qui est traitée dans l'ordre de la microseconde la création d'un thread n'est pas un souci. Ou alors en systèmes embarqués on aurait carrément des soucis avec des changements de contexte et de la synchronisation à la nanoseconde.

[fxrobin]

Dans ce qu'il disait je pense qu'il ne parlait pas de créer un propre serveur HTTP.
Explique pourquoi il ne faut pas créer de thread dans le traitement HTTP

Salut, tout simplement parce que la SPEC (JEE) le déconseille.
Et d'ailleurs Gugelhupf avait donné de très bons liens à ce sujet :

"Creating your own threads inside an application server is generally discouraged because the server should manage threads for better scalability. You can also run into problems if the container makes assumptions about what's available in a thread context, such as security information (e.g., authenticated Subject). That typically happens if you spawn a thread and then use a server resource from that thread which is unknown to the container.

Check to see if there is a way to get container managed threads from Tomcat. WebLogic and WebSphere support the commonj.WorkManager, which allows you to schedule work on container managed threads. Spring can also use commonj, but I'm not sure if that support is available on Tomcat."

C'est ce que je disais plus haut. C'est le serveur d'application qui gère les Threads et doit pouvoir s'arrêter et se démarrer ... s'il y a des Threads qui trainent en cours d'exécution, seul un arrêt brutal de la JVM permettra de tout stoper, ce qui est très mauvais.

Plus d'explications ici : http://stackoverflow.com/questions/5...is-discouraged

[alex_vino]

Merci pour les liens.
En fait c'est vraiment spécifique a la plateforme et au language.
Mais quand je parle de développement multithreadé je ne dis pas de faire chaque opération dans un nouveau thread, mais plutot de multithreader des requetes couteuse en temps tel I/O (fichiers, web services...).
Apres bien évidemment certaines choses doivent tourner en arriere plan comme l'envoie d'email par exemple.
Apres il est vrai que le développement web ne nécessite pas forcément d'utiliser le multithreading, ou celui-ci peut etre fait avec des requetes Ajax depuis le client.

[fxrobin]

Pour être vraiment complet, JEE est multithread "à tous les étages" ... que ce soit les Servlet, les JSP, les EJB, etc ... et HEUREUSEMENT ...

Ce qui est "déconseillé" c'est de laisser au développeur le contrôle des Threads (création, terminaison) car ce doit être le serveur d'applications qui doit les gérer. Si on souhaite faire "des threads" (c'est à dire du traitement asynchrone, de la parallélisation) il y a tout ce qu'il faut sans devoir "descendre à la cave" (c'est à dire utiliser des Threads de bas niveau) : EJB Timer, Worker, EJB Asynchrones, JMS, JCA.

[rimram31]

En principe tu ne crées pas de thread directement car c'est une opération assez coûteuse...

Amusant quand un développeur Java va vouloir économiser la création d'un thread, d'une connexion database, un appel réseau, même du pool d'objets pour soulager le gc ... gagner ici et là quelques millisecondes et des ressources, là où en PHP on se satisfait de faire du 50 req/s.

En se baladant sur le net on trouve d'ailleurs quantité d'articles pro PHP se posant des questions sur le coût d'un framework qui vient grosso modo diviser par 10 ton throughput. Allez, je remet une pièce: http://blog.dhananjaynene.com/2008/0...-jruby-groovy/, pour autant, et heureusement pour PHP, le critère de performance du langage ne sera pas le seul retenu.

[fxrobin]

Effectivement je pense qu'Andi Gutmans devra trouver quelque chose de plus crédible pour "dé-crédibiliser" les autres plateformes, et en particulier JAVA.

Par exemple, ces benchmarks montrent JAVA bien plus rapide et bien plus performant que du PHP ... : http://shootout.alioth.debian.org/u3...java&lang2=php

En revanche, on peut constater que PHP consomme moins de mémoire ... mais c'est tout à fait logique compte tenu des architectures si différentes entre les deux plateformes.

[Elendhil]

Je suis surpris jusqu'à 50 fois moins rapide sur certains algos qu'avec Java 7

[_skip]

Pour une requête qui est traitée dans l'ordre de la microseconde la création d'un thread n'est pas un souci. Ou alors en systèmes embarqués on aurait carrément des soucis avec des changements de contexte et de la synchronisation à la nanoseconde.

Fais un test de montée en charge un peu sérieux en créant un nouveau thread à chaque requête et ensuite refait la même chose en délégant le même traitement à un exécuteur qui réutilise les threads. Tu sentiras bien la différence, sans compter la mémoire, chaque thread ayant sa propre pile, quand tu commences à en spawner 200 par secondes...

Après seulement je te propose de venir dire que créer des threads à tout va ça a presque aucune incidence, qu'on s'en fout.

[transgohan]

Fais un test de montée en charge un peu sérieux en créant un nouveau thread à chaque requête et ensuite refait la même chose en délégant le même traitement à un exécuteur qui réutilise les threads. Tu sentiras bien la différence, sans compter la mémoire, chaque thread ayant sa propre pile, quand tu commences à en spawner 200 par secondes...

Après seulement je te propose de venir dire que créer des threads à tout va ça a presque aucune incidence, qu'on s'en fout.

C'est gentil de me faire dire ce que je n'ai pas dit...
Je suis au plus à même de pouvoir répondre puisque justement je travaille sur des benchmarks de système d'exploitation et donc dans tout cela rentre les créations de process et compagnie. On ne balance pas des threads pour n'importe quoi, mais ce n'est pas pour autant qu'il faut dire qu'il ne faut pas en créer parce que c'est une hérésie niveau temps de création car c'est totalement faux.

D'autant plus que ton réutilisateur de threads qui met les contextes en cache il s'appelle l'OS justement... Balances 100 threads et consultes leur contexte et leur id avec et sans ton exécuteur et tu verras que les tid vont se répéter, que toutes les variables générées aléatoirement auront bizarrement les mêmes valeurs, ect. Bref je serai bien curieux de voir le code de ce système de la JVM si c'est autre chose qu'un simple pont vers l'OS.
Je ne sais pas si windows le fait, mais en tout cas c'est le cas de tous les Unix que j'ai testé.

[_skip]

C'est gentil de me faire dire ce que je n'ai pas dit...

Relis ce que tu as dit, et met ça dans le contexte, soit la création de thread par requêtes sur un serveur. Tu sous-entends clairement qu'on peut le faire, que c'est parfaitement raisonnable, ou alors tu voulais dire que c'était raisonnable pour un blog qui a 50 visites par jour je sais pas...

On ne balance pas des threads pour n'importe quoi, mais ce n'est pas pour autant qu'il faut dire qu'il ne faut pas en créer parce que c'est une hérésie niveau temps de création car c'est totalement faux.
(...)

Fais le test dont j'ai parlé, tu verras.... Je ne vais pas discuter pendant des heures avec toi sur la façon dont on peut présumer qu'un thread java map sur un "vrai" thread OS. Il est admis que créer des threads pour des opérations courtes et fréquentes est pas une bonne idée, c'est pour ça que les POOLs existent et d'ailleurs qu'ils sont déjà utilisés par tous les serveurs web dont j'ai connaissance pour gérer les requêtes des clients.
Et il y a aussi l'argument de la mémoire nécessaire pour la pile, ça fait beaucoup quand on les multiplie par 100 voire 1000. Donc je te dis, créer des threads lors de chaque requête sur un serveur sachant que tu peux avoir à supporter un important stress, c'est pas bon.

[pcaboche]

Ce n'était pas une critique, le simple constat que si tu as des contraintes similaires, tu vas utiliser des approches similaires et les architectures vont inévitablement converger. La complexité ne vient pas de la techno elle-même (quoique parfois ...) mais du problème que tu as à résoudre :-)

J'aurai la même réponse pour ce qui est des "experts", m'intéressant autant aux problèmes qu'ils ont eu a résoudre qu'aux technologies qu'ils maîtrisent. Finalement, quand on parle 4 ou 5 langues d'origine différentes, en apprendre une autre n'est pas difficile. J'ai là plutôt appris a me méfier des "dogmatiques" dans lesquels on trouve beaucoup d'"experts Java"

Ce message est extrêmement intéressant.

En effet, face à un problème informatique, dans le meilleur des mondes on appliquerait la méthode suivante :

• analyser le problème
• réfléchir à la manière de résoudre le problème
• analyser les différentes technologies disponibles
• choisir la technologie la plus appropriée (si on ne la maîtrise pas, on peut toujours apprendre)
• implémenter

Seulement on prend souvent le problème dans l'autre sens :

• on commence par choisir la technologie (en fonction de l'existant ou d'autres choix plus "politiques" au sein de la société)
• on implémente
• on essaye de trouver des solutions de contournement ("workaround") face aux problèmes que l'on rencontre

Parallèlement, côté technologie, il y a un autre effet pervers...

Lorsqu'une technologie rencontre certaines limitations, il existe en gros 2 approches possibles :

1. on repense la technologie (parfois drastiquement) pour éliminer ces limitations
2. on désigne comme "expert" les personnes connaissant les méthodes de contournement face aux limitations de la technologie. Dans le même temps, on produit des cours et des certifications que l'on vend très cher aux personnes souhaitant être reconnues "expert"

Généralement, on choisit la deuxième solution car plus simple et plus rentable...


Partant de là, l'industrie a inventé son propre lexique, qu'il faut savoir décoder :

"expert X" (avec X = Java | .Net | php |...) : personne connaissant les méthodes de contournement face aux limitations d'une technologie, soit par l'expérience, soit pour avoir bachoté une certification

"développeur X, avec expérience dans le framework machin" : si vous êtes développeur X, avec expérience dans le framework bidule, on considérera que vos connaissances ne sont pas transférables, dans le seul but de justifier une baisse de salaire.

"certifié X" : plusieurs définitions possibles :

• personne avec expérience en X, a payé une certification pour que son expérience soit reconnue / parce que le client l'exige
• personne ayant une expérience similaire, voulant se ré-orienter vers X, la certification servant de raccourci vers ce but
• personne ayant bachoté la certification X pour se faire appeler "expert"

Finalement, quand on parle 4 ou 5 langues d'origine différentes, en apprendre une autre n'est pas difficile.

Vrai en informatique, pour autant que les langages appartiennent au même paradigme de programmation.

Une bonne connaissance en informatique passe surtout par la maîtrise d'un ou plusieurs langage dans différents paradigmes (impératif, orienté-objet, déclaratif, fonctionnel, logique...).

Comme dit précédemment, l'important c'est surtout d'apporter des solutions cohérentes pour résoudre un problème (ce qui implique parfois de connaître d'autres technologies que ce qu'on utilise tous les jours).

En résumé, je partage globalement ton avis concernant ces fameux "experts" (et ai appris à décoder le langage utilisé sur le marché du travail, et à me méfier de ses travers).

[rimram31]

...En résumé, je partage globalement ton avis concernant ces fameux "experts" (et ai appris à décoder le langage utilisé sur le marché du travail, et à me méfier de ses travers).

Il ne faut pas tout jeter :-) un développeur, une équipe capitalise sur un ensemble de technos, dans notre discussion ici une équipe avec un fort existant Java avec du script au dessus de la plateforme sera plus efficace qu'avec du PHP.

Mais coté profils, c'est du coté de Java que j'ai croisé le plus de "gourous" (genre EJB, Struts, hibernate, NoSQL aujourd'hui...) qui font parfois plus de dégâts que de bien a un projet, ignorant et même dénigrant toute solution simple parce que la technologie ne serais pas "noble". Au delà de l'apprentissage d'un nouveau langage, changer d'air, ça permet de découvrir d'autres catégories de problèmes, de solutions, de points de vue qui enrichiront ton expérience même dans ta propre "techno". J'ai appris coté recrutement à me méfier de certains "experts" qui peuvent te ruiner le travail de toute une équipe, leur préférant des profils plus atypiques, plus "baroudeurs" des technologies.

En rapport avec le débat initial, résumer un service web a des pages PHP, son "front office", c'est pour le moins simpliste et loin de la réalité, en tout cas de la mienne. Ce n'est que la partie immergée de l'iceberg, sa partie publique, tout service web aura son back office, ses connexions avec des SI, des partenaires, des fournisseurs, ses besoins d'exploitation, de statistiques, de reporting ... Là, je ne suis pas du tout convaincu qu'une seule technologie puisse y répondre, il faudra au contraire probablement en utiliser plusieurs selon l'ensemble de ses besoins.

[transgohan]

Relis ce que tu as dit, et met ça dans le contexte, soit la création de thread par requêtes sur un serveur. Tu sous-entends clairement qu'on peut le faire, que c'est parfaitement raisonnable, ou alors tu voulais dire que c'était raisonnable pour un blog qui a 50 visites par jour je sais pas...



Fais le test dont j'ai parlé, tu verras.... Je ne vais pas discuter pendant des heures avec toi sur la façon dont on peut présumer qu'un thread java map sur un "vrai" thread OS. Il est admis que créer des threads pour des opérations courtes et fréquentes est pas une bonne idée, c'est pour ça que les POOLs existent et d'ailleurs qu'ils sont déjà utilisés par tous les serveurs web dont j'ai connaissance pour gérer les requêtes des clients.
Et il y a aussi l'argument de la mémoire nécessaire pour la pile, ça fait beaucoup quand on les multiplie par 100 voire 1000. Donc je te dis, créer des threads lors de chaque requête sur un serveur sachant que tu peux avoir à supporter un important stress, c'est pas bon.

Je voulais faire un edit pour pas continuer un débat inutile mais ça me barbe en fait de me prendre des coups de bâtons parce qu'on lit mes messages en diagonale et qu'on veut troller...

Bien... J'ai dit que la raison que vous invoquiez n'était pas correcte. Pas que dans le fond vous n'aviez pas raison...
La pile d'un thread de traitement de l'ordre de la microseconde ne pourra pas excéder une certaine taille en raison de la vitesse de chargement en mémoire. Donc il est possible de créer 1000 threads sans soucis. Le problème survient si les threads deviennent zombies. Là on plombe le serveur en peu de temps. Et c'est pourquoi il y a ce contrôleur (pool de threads).

Va-t-on encore une fois rajouter des mots à mon dialogue ?

[_skip]

La pile d'un thread de traitement de l'ordre de la microseconde (...)

On ne crée que rarement des threads pour effectuer des opérations qui durent une microseconde, enfin c'est assez peu commun à mon sens. Donc oui peut être as-tu raison dans ce cas qui est pour moi un peu extrême. En fait vu que tu prends le truc assez mal on va arrêter ça (c'est vrai que si je relis mon premier post à ton encontre c'était pas très sympa et je me suis pas rendu compte alors je te présente mes excuses en guise de conclusion.)

[miboo]

"java trop lourd et trop lent"

on peut pas lui en vouloir en même temps, il prêche pour sa paroisse ...

Et c'est quoi la réponse si évidente à cette question ?
J'ai déjà lu des débats sur compilé vs interpreté, mais j'ai du mal à comprendre pourquoi je vois beaucoup d'application Java assez basique et pourtant très lente comparé à la même chose en PHP. Facebook qui est une application qui doit nécessiter une performance de malade a pourtant fait le choix d'un PHP (adapté). Et ce n'est qu'un exemple parmi d'autres.

Autant, je comprends le côté industriel de JAVA, et la fulltitute d'outils qui existent pour créer une application robuste. Autant sur la performance je m'interroge. En dehors de la preche, sur quoi se base Andi pour dire que Java est trop lent ?