Discussion :

[Bluedeep]

Cette stats, c'est le serpent qui se mord la queue sur ce débat, elle résulte tout simplement de l'offre d'hébergement "grand public" .

Oui, mais on apprend aussi que :

97.0% of all web servers in Uzbekistan run on PHP. .

Php, spécialité ouzbekh ?

[Grabeuh]

Yep, suis du métier t'inquiètes pas En Java, tu feras de la répartition de charge avec préférence au même serveur, bascule uniquement en cas d'indispo et du coup tu ne mettras en cache distribué que le minimum pour assurer ta continuité de service et tes caches du même coup, sont fortement optimisés (et répartis). [...]

Dans une expérience antérieure, nous avions presque tout en mémoire, seules les écritures obligeaient a invalider les caches et probablement quelques erreurs de design qui nous obligeaient a devoir redémarrer les serveurs nos caches mangeant toute la mémoire ... Nous avions été incapables de mettre en place un cache distribué, la charge réseau nous faisant mourir la plateforme en quelques secondes.

Effectivement, avec ce retour d'expérience, je comprends mieux ton raisonnement.
Merci pour ces infos.

[EDIT anti-double post]

outefois intéressant de lire l'autre stat de w3tech: http://w3techs.com/technologies/tops...mming_language où, si j'ai tout compris, quand ça devient sérieux, on change vite de techno :-) c'est bien ce qui est dit ici.

Leur graphique est un peu étrange à comprendre, mais en suivant leur système de calcul, pour les 1000 sites les plus visités selon le classement Alexa, on se retrouve avec les stats suivantes (ils expliquent qu'on peut dépasser les 100% car certains sites utilisent plus d'une techno à la fois):

PHP : 60,23% (78,3 / 1,3)
.NET : 22,88% (20,8 x 1,1)
Java : 16,4% (4 x 4,1)
Python : 3,02% (0,2 x 15,1)

L'écarte diminue, mais le classement reste grosso modo le même pour le trio de tête.

PS : si ça peut te rassurer, j'accorde autant de crédit que Churchill à ces chiffres :

Je en fais jamais confiance à des chiffres que je n'ai pas falsifié moi-même

[rimram31]

Effectivement, avec ce retour d'expérience, je comprends mieux ton raisonnement.

10 millions de hits/jour, des pics a 1000 requetes/s, partant du fait qu'une requête http effectue "quelques dizaines" d'opérations disons élémentaires, tu te retrouves avec quelques dizaines de milliers de transactions par seconde a traiter et ou la milliseconde devient une éternité :-) tu vois les choses un peu autrement.

Donc quand tu vois débarquer une techno sans pool de connexion database, sans multi threading, avec de l'OO scotché "à la va vite", qui t'explique que les layers comme le MVC ça sert à rien, n'a aucune "structure" (la mémoire dont je parle plus haut), tu es pour le moins sceptique. Tu ajoutes à ça des développements PHP que tu récupères avec du SQL dans le code HTML sans aucun layer métier avec par exemple pas un seul index posé sur une table, tu as une petite idée de ce que peut être mon sentiment

Cela étant dit, très probable que demain la grande majorité des développements soient fait en PHP sans même connaitre une approche comme Symfony et sans même avoir besoin de poser un index en base. Notre débat autour de PHP ressemble pour beaucoup a un vieux débat sur Visual Basic. D'expérience, je sais que Visual Basic a fait énormément de dégâts, qu'en sera-t-il de PHP, rendez-vous dans quelques années

[Grabeuh]

Il ne faut pas non plus jeter le bébé avec l'eau du bain.

Certes, le langage est bancal : il a une API inconsistante, des mécanismes relevant plus du spiritisme que de la logique dans certains cas, un modèle objet rafistolé qui tient avec un bout de ficelle. Mais ça ne l'empêche pas de remplir son rôle et de répondre à un besoin : développer une application web.
Quand on regarde bien :

• La première Twingo n'avait pas de motorisation Diesel alors qu'en France on roule majoritairement au Diesel. C'est pas ça qui l'a empêché d'être une des voitures les plus vendues de sa génération.
• L'iPhone 1 ne gérait pas la 3G, ne savait pas ce qu'était un copier/coller ni un MMS. Ca a pourtant été un succès qui a modifié en profondeur le paysage de la téléphonie mobile.
• Le garbage collector des premières versions de Java était une vraie plaie et a donné en grande partie sa réputation de "lourd et usine à gaz" au langage. Pourtant Java a été un succès aussi et il s'est amélioré avec le temps.

Oui, il y a d'autres langages qui ont des meilleurs outils pour faire du web, qui ont de meilleures performances ou qui permettent de faire un code plus propre.
Oui, PHP essaye de combler ses lacunes en piquant à droite et à gauche des idées et les agrège sans vraiment de cohérence.
Mais les défauts de PHP sont négligeables comparé à ses atouts : simplicité de mise en oeuvre, simplicité de mutualisation chez les hébergeurs, sa capacité d'adaptation (j'ai vu des gens faire des daemons systèmes en php) et sa simplicité d'apprentissage (qui est du en grande partie au fait qu'il pique à droite et à gauche, on retrouve assez vite ses repères quand on vient d'un autre langage)

Je veux aussi dire que des projets php sont souvent ignobles, mais là c'est de la responsabilité du développeur qui a réalisé ce projet.
Un mauvais développeur va te faire un programme C++ bourré de fuites mémoire et de bugs de dépassement de tampon. Un développeur consciencieux t'en fera un propre et sobre.

Alors oui, je concède qu'il y a effectivement ENORMEMENT de mauvais développeurs PHP et donc de code "hachis parmentier" (pour changer du code spaghetti) avec le code métier / les accès DB / le html qui se mélangent.
Mais l'industrialisation (qui repose en grande partie sur des outils issus du monde Java) dont je parlais plus tôt sont en train de rentrer dans les moeurs et améliore grandement la qualité des projets développés avec PHP.

Aujourd'hui, un projet sérieux sera réalisé en intégration continue, avec des tests unitaires automatisés, et produira des rapports sur la qualité du code avec des analyses statiques, des recherches code dupliqué, etc.
Il utilisera un framework MVC dans 95% des cas, que ça soit Symfony2, ZF2 ou un autre moins connu, voire une solution maison.

Mais l'idée est là : si on veut gagner du temps et donc de l'argent, et limiter la maintenance, il faut bosser proprement.

Alors, effectivement, tu n'as pas certains outils bien pratiques comme un pool de connexion DB, de multithreading ou autres. Cependant, la communauté s'est toujours débrouillée sans et a réussi à réaliser des projets importants, de Facebook à Wordpress en passant par Magento. Faut juste savoir s'adapter aux limitations de son outil et tirer parti de ses avantages.

[rimram31]

Il ne faut pas non plus jeter le bébé avec l'eau du bain.

Pas de soucis, je suis même un défenseur du scripting depuis des années (et déjà python ...) n'ayant jamais compris pourquoi on s'entête a faire compliqué quand on peut faire simple. Toutefois il est préférable de savoir pourquoi on peut faire simple :-) tout en ayant conscience des dangers. Si je cite plus haut VB, c'est que j'ai vu a cette époque des "décideurs" embarquer de pauvres types dans des suicides collectifs au prétexte que c'était "facile".

Pour revenir a la question initiale du développement web, je crois plutôt en des outils, des frameworks qui embarqueront des composants élaborés (qui auront résolu nombre de problèmes tordus ...) avec lesquels on développera, pourquoi pas, en PHP pour la "glue", mais quantité d'autres langages de scripts pourront aussi bien faire l'affaire.

[Gugelhupf]

Donc quand tu vois débarquer une techno sans pool de connexion database, sans multi threading, avec de l'OO scotché "à la va vite", qui t'explique que les layers comme le MVC ça sert à rien

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 ).

Multi threading : 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à). Après à ce que je sache on ne fait pas beaucoup de développement graphique avec PHP même si PHP-GTK existe.

l'OO scotché "à la va vite" : J'avoue que les classes en PHP ne sont pas aussi bonnes qu'en Java/C#/C++ principalement à cause de 3 problèmes (selon moi) :

• les constructeurs qui agissent comme de simples méthodes.
• la non obligation de déclarer les attributs directement utilisés dans le constructeur
• l'usage abusif des méthodes magiques __get() et __set() pour certains développeurs.

Malgré cela, il est possible de faire du bon POO si on s'applique bien.

les layers comme le MVC ça sert à rien : Ne me dis pas que tu ne peux pas faire d'affichage via une servlet ? D'ailleurs tu n'es même pas obligé d'avoir une JSP. Là encore si tu utilises un framework (Struts pour Java ou Symfony pour PHP par exemple) tu auras du MVC.

[alex_vino]

Multi threading : 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é

En ASP.Net le multithread est conseillé justement! Et il y a beaucoup d'avantage, si tu n'en voit pas je peux te parler de performance déja.

Dire que le MVC ne sert a rien c'est ne l'avoir jamais pratiqué, ou ne pas maitriser le but recherché. Il n'est pas toujours adapté en fonction du projet, mais bien souvent il l'est et quand on y goutte on a du mal a s'en passer.

[camus3]

Code :

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

l'usage abusif des méthodes magiques __get() et __set() pour certains développeurs.

Au contraire les méthodes magiques de PHP , c'est ce qui fait sa force et permet au développeur PHP de faire de la métaprogrammation.
PHP est un langage de script,et un langage de script si il n'est pas hautement réflexif et ne permet pas la génération de classes, de méthodes, de les étendre au runtime n'a aucun intérêt, puisque c'est la contrepartie du typage dynamique!

Ruby ou Python poussent encore plus loin ce concept, ce qui leur permet d’accélérer le développement de façon exponentiel par rapport à Java ou même à Php.

[rimram31]

Pool ... Multithreading ... MVC ...

Je faisais du pool de connexion en 2000 en Java "web" (et du templating avec webmacro!), tu trouvais des implémentations de pool un peu partout (j'ai d'ailleurs du retravailler très sérieusement la notre car elle n'était pas trop concurrente :-)). C'est le modèle d'architecture du PHP qui ne le permet pas, mais depuis, d'après ce que j'ai lu, le problème est réglé puisque géré par les implémentation de driver. En MySQL ce n'est pas trop un souci (ouverture de connexion rapide), en Oracle ça devient plus que gênant. Ne pas avoir la capacité de gérer sa ressource database dans des applications a fort trafic est une impasse.

Concernant les thread, justement mon "pool" en utilisait pour vérifier la cohérence du pool mais aussi le rafraichir (une vieille connexion peut devenir gourmande). Après c'est une technique courante en web de décaler des traitements pour pouvoir répondre plus rapidement quand ces traitements n'ont pas d'importance pour le rendu dans la vue.

Enfin pour le MVC, ce n'est pas moi qui le dit mais Ramus Lerdorf qui explique que justement, il a créé PHP quand on n'avait pas besoin de toute cette "plomberie" et apparemment un framework comme Symfony est en contradiction avec sa "philosophie" du langage. Sur le fond, je ne peux que lui donner raison, les choses vont un peu mieux aujourd'hui en web 2.0 et une plus grande granularité des modèles, mais le MVC des débuts était assez infâme, sans parler de Struts .... et j'avoue que j'ai souvent triché en poussant des factory dans la vue :-) J'ai toujours trouvé stupide de devoir "pousser" tous les objets possibles quand bien même la vue, par nature dynamique, n'en a pas nécessairement besoin. Plus efficace quand c'est la page qui peut "tirer" les objets dont elle a besoin.

Mais comme le dit Grabeuh plus haut, peu a peu des solutions seront trouvées en PHP pour les problèmes à résoudre. A voir si la communauté PHP aura le même dynamisme qu'a pu avoir celle de Java, ce dynamisme tenait pour beaucoup au fait que Java était portable.

D'un autre coté PHP doit son succès au fait que l'on trouve facilement des solutions d'hébergement et de ce coté là, ça pourrait bouger et changer la donne en faveur d'autres technos.

[Gugelhupf]

En ASP.Net le multithread est conseillé justement! Et il y a beaucoup d'avantage, si tu n'en voit pas je peux te parler de performance déja.

N'ayant pas fait d'ASP .Net je ne sais pas du tout à quel niveau les thread sont utiles.
En Java ou PHP on peut exécuter un script externe par exemple (exemple java, ou php ici et là).
Qu'entends-tu en par "performance", normalement l'exécution d'un bloc prend moins de temps que s'il est exécuté via un thread... Pour moi les thread sont juste censé rendre l'expérience utilisateur plus agréable au niveau de l'affichage... Sauf qu'avec le modèle MVC tu exécutes tout sur la couche Controlleur puis dans un second temps affiche dans la View, donc par curiosité :
Pourquoi, quand et à où (où = M, V, ou C) se servir des Thread en ASP ?

Au contraire les méthodes magiques de PHP , c'est ce qui fait sa force et permet au développeur PHP de faire de la métaprogrammation.

Pour avoir travaillé en équipe avec une application maison qui abusait des méthodes magiques je n'ai pas du tout aimé.
Si toi pouvoir bien maintenir ça, moi me consterner :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
<?php
class Client
{
	public $disabled = 1;

	public function __construct($id = null)
	{
		$this->id = $id;

		if($id instanceof Personne) {
			$this->personne = $id->id;
			$this->id = $id->client;
			$this->idc = $id->idc;
		}

		if($this->id) {
			$this->Load();
                }
	}

        public function __get($name) {
            $method = 'get' . ucfirst(strtolower($name));

            switch ($name) {
                case 'libelle':
                    return trim($this->nom . ' ' . $this->prenom);
                    break;
                case 'nb_rdv':
                    return $this->getNbRdv();
                    break;
                default:
                    if (method_exists($this, $method)) {
                        $data = $this->$method();
                    } else if ($this->$name) {
                        $data = $this->$name;
                    } else {
                        throw new Exception("la methode $method n'existe pas($name)");
                    }
                    break;
            }

            return $data;
        }

	public function Load()
	{
	    if(!$this->id) {
	        return;
            }
            // ETC... 
        }

}

Après si j'avais créé l'outil moi-même avec ces méthodes magiques je n'aurais rien dis bien sur .

[alex_vino]

@Gugelhupf: Le probleme de tes exemples c'est que ce sont des scripts externes qui bloquent le thread courant.
Quand je te parle d'application multithreadé c'est quand l'appel d'un script ne bloque pas le thread principal.
Par exemple si ton application doit récupérer une valeur d'un WebService puis insérer a la fois cette valeur dans la base de données et dans un fichier XML, tu pourras faire tout cela de facon asynchrone. Tu pourras insérer dans la base de données et mettre a jour ton fichier en meme temps.
Si tu effectue cela dans ton thread principal tu va devoir additionner tous tes temps des opérations ci-dessus, ce qui n'est pas judicieux car ce sont les opérations I/O qui prennent le plus de temps.
Sans multithread: Temps total = Temps écriture base de données + temps écriture fichier XML
Avec multithread: Temps total = Max ( temps DB ; tmps fichier )

Tout cela se faisant dans ton controlleur. Depuis le .Net framework 4.5 il ne faut seulement que 2 mot-clés pour effectuer une opération asynchrone (par exemple écrire dans un fichier), ce qui est grandiose.
Par contre il est évident que toutes les applications ne requierent pas forcément d'utiliser le multithreading.

[camus3]

Si toi pouvoir bien maintenir ça, moi me consterner

le code est parfaitement lisible, dans la deuxième partie du __get() , est implémenté un getter implicite , ce qui est courant en PHP. je vois pas en quoi ce n'est pas maintenabe, si la classe est documentée... Par contre à ta charge ( et ton équipe ) de se mettre d'accord sur certaines conventions, cela me semble normal. PHP a beaucoup de problèmes , mais les méthodes magiques n'en font pas parti, au contraire , c'est un des atouts de PHP.
On peut par contre parler des 1000 fonctions étrangement bordéliques et nommées de php, ça ne n'est pas "retenable"

D'un autre coté PHP doit son succès au fait que l'on trouve facilement des solutions d'hébergement et de ce coté là, ça pourrait bouger et changer la donne en faveur d'autres technos.

En fait je dirais même que "l'industrialisation" d'un projet PHP fait disparaître les avantages de "simplicité" par rapport à d'autres technos comme Ruby ou Python.
Si je suis capable d’accéder à mon serveur en SSH, compiler une extension PHP dessus, écrire un hook post-receive , créer un virtual host sur apache , je vois pas en quoi il est plus complexe de déployer Rails ou Django, surtout avec la tonne d'outils qui existe pour ces différentes solutions.
Java reste plus problématique à déployer.

[rimram31]

[quote=camus3;6961702}...Java reste plus problématique à déployer.[/quote]
Je voulais dire que si on se remet dix ans en arrière, on aurait difficilement imaginé l'évolution des solutions d'hébergement, donc qui sait ce qu'il sera dans quelques années. Finalement, une webapps Java doit pouvoir se mutualiser sans trop de difficulté, jetez un oeil a jelastic par exemple, j'avais rêvé d'avoir ce genre de truc il n'y a pas si longtemps ...

Ce me fait d'ailleurs penser que la mutualisation comporte quand même ses limites, ce sont les contraintes sur les versions des différents composants que l'on utilise. Pour l'instant, seuls Unix, MS aussi, Java et Python a ma connaissance se sont retrouvés face a ce problème pour le moins épineux de la gestion des dépendances quand, succès oblige, tu te retrouves avec des centaines de librairies dans cinquantes versions différentes a gérer.

Ce que tu dis sur l'industrialisation de PHP me fait penser que Java, Python et bien d'autres technos, a leur création, se voulaient "simplissimes" (et l'étaient), c'est bien parce que beaucoup de gens utilisent la techno que les choses se compliquent ensuite

[Grabeuh]

Pour remplacer assez simplement le multithreading en php, généralement je me sers de ZeroMQ pour créer un pool de workers asynchrones qui tournent en tâche de fond et servent uniquement à effectuer une seule opération puis attendent qu'on leur donne d'autres ordres.

Derrière, ça nécessite de repenser complètement l'architecture de son application mais du coup, ça permet aussi de faire un système distribué beaucoup plus simplement.

C'est d'ailleurs le principe de Photon, qui utilise Mongrel2 au lieu d'Apache.
Photon, le nouveau framework PHP qui va vite

[camus3]

Je voulais dire que si on se remet dix ans en arrière, on aurait difficilement imaginé l'évolution des solutions d'hébergement, donc qui sait ce qu'il sera dans quelques années. Finalement, une webapps Java doit pouvoir se mutualiser sans trop de difficulté, jetez un oeil a jelastic par exemple, j'avais rêvé d'avoir ce genre de truc il n'y a pas si longtemps ...

En fait si tu utilises certains PAAS, java est relativement facile à déployer. D'ailleurs il est encore plus facile à déployer quand le PAAS supporte directement tel ou tel framework ( je pense à Heroku , qui d'ailleurs ne support pas PHP officiellement , tu dois écrire ton propre script qui va installer PHP, Apache et compagnie)

MS aussi, Java et Python a ma connaissance se sont retrouvés face a ce problème pour le moins épineux de la gestion des dépendances quand,

Pour python tu as virtual env qui va te permettre d'installer plusieurs versions de django et de toutes les libs utilisées sur un même serveur
sans avoir de clash entre elles.donc quand tu télécharges une lib avec PIP , elle ne va pas écraser celle d'un autre projet.

[rimram31]

Pour remplacer assez simplement le multithreading en php, généralement je me sers de ZeroMQ ...
...C'est d'ailleurs le principe de Photon...[/url]

Et au final tu réinventes un serveur d'application Java avec son JMS. Pour peu que tu intègres du scripting (JSR223) sur ta plateforme Java, tu te retrouves avec les mêmes technos :-) mêmes avantages et inconvénients (sauf que tu auras le choix du langage de script).

Ton lien sur Photon est intéressant, même si on doit toujours être critique envers les benchmarks, il nous explique qu'en gros il gagne un rapport 40 ou 50 en performance (1 dual core vs 20 x8). Ce n'est rien d'autre que ce que j'essaie d'expliquer dans ce thread, si ton trafic est de qques requêtes minutes, pas de question a se poser, mais si tu atteint la capacité de ta plateforme, ça vaut le coup de se poser la question de diviser par 50 tes coûts de hosting (d'autant que d'expérience, ce n'est pas du tout linéaire). Mais comme je le dis plus haut, il est probable que plus de 90% des développements web n'aient pas de question de trafic a se poser.

Pour python tu as virtual env qui va te permettre d'installer plusieurs versions ...

Pas utilisé, je fais peu de Python, mais j'en connaissais l'existence, j'ai pas mal galéré par contre en Java avec ça. Dès que tu assembles 3 composants "évolués", tu te retrouves avec des dépendances a gérer, sans parler de tes propres versions applicatives que tu ne peux pas toujours upgrader facilement (d'où OSGi et les réflexions sur les class loader dans les JVM).

Je me faisais la réflexion que si PHP a un succès comparable a Java ou Python, il aura dans peu de temps les mêmes problèmes a régler.

[transgohan]

Et au final tu réinventes un serveur d'application Java avec son JMS. Pour peu que tu intègres du scripting (JSR223) sur ta plateforme Java, tu te retrouves avec les mêmes technos :-) mêmes avantages et inconvénients (sauf que tu auras le choix du langage de script).

Sauf que la technologie PHP n'a jamais eu pour objectif de devenir un serveur stand-alone contrairement au JEE. Donc je ne vois pas le mal que tu cites...
Tu compares donc des choux avec des bananes en prétextant que la banane a une peau contrairement au choux.

[rimram31]

...Tu compares donc des choux avec des bananes en prétextant que la banane a une peau contrairement au choux.

Ce n'est pas moi qui transforme les choux en banane mais bien les initiatives citées plus haut, à savoir un "PHP application server" (photon) doublé d'un serveur de messaging (ZeroMQ). Ce que je trouve intéressant par contre c'est que leur argument massue est d'expliquer qu'une telle architecture permet un gain de 3 a 10 sur une approche "classique" PHP.

Je vais me répéter, mais la seule question a se poser est de savoir si tu as besoin ou non d'une telle complexité, si oui, je connais beaucoup de décideurs qui seront sensibles a une réduction par 10 de tes coûts d'hébergement et d'exploitation.

[transgohan]

Ce n'est pas cet aspect là que je te reprochais, ce que je disais c'est que je vois pas pourquoi tu critiques son choix.
Ton message laissait à penser que c'était risible de créer cette banane à partir du chou qu'est PHP alors que la banane java existe déjà.
Tout le monde ne peut pas se permettre de jongler avec toutes les technologies existantes dans le monde tous les jours. Surtout qu'avec une approche comme celle-ci on perd l'expertise (ingénieur 5ans d'expérience - expert Java, C/C++, PHP => moi je répond "expert" ???)

Cela dit je reste tout à fait d'accord avec le reste de tes propos, je ne pense pas qu'il y ait beaucoup de projets PHP qui nécessitent une telle infrastructure.

[rimram31]

Ce n'est pas cet aspect là que je te reprochais...

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"