PHP s’imposera sur les serveurs face à Java et .NET

[_skip]

S'il y a bien en revanche un point sur lequel PHP semble s'approcher de Java, c'est la multiplication des gros ORM et gros framework usine à gaz qui font plein de magie noire.
Assez regrettable pour une techno qui se voulait souple et facile à prendre en main. J'ai mis mon nez dans pas mal de grosses plateformes ecommerce dernièrement, le genre qui tourne que sur un gros serveur, et je me suis vraiment demandé si on essayait pas de lui faire avaler n'importe quoi à ce pauvre PHP, d'en faire du J2EE dans le mauvais sens du terme.

[alex_vino]

Envoyé par rimram31

Disons que je vois mal un développeur lambda PHP (et bien d'autres d'ailleurs ...) s'attaquer a un problème genre celui-ci: http://www.facebook.com/note.php?note_id=39391378919 Maintenant c'est sûr que si ton site traite qques requêtes/minute, tu as toute latitude du choix des outils de développement.

Je n'ai pas une grane expérience en PHP donc je ne m'exprimerais pas sur la performance des projets d'envergure en PHP.
Par contre dans le lien que tu vient de donner on remarque que l'URL n'est pas tres jolie, par contre d'autres technologies génererait en natif ce type d'URL: http://www.facebook.com/note/Scaling...ed-at-Facebook

[transgohan]

Envoyé par alex_vino

Je n'ai pas une grane expérience en PHP donc je ne m'exprimerais pas sur la performance des projets d'envergure en PHP.
Par contre dans le lien que tu vient de donner on remarque que l'URL n'est pas tres jolie, par contre d'autres technologies génererait en natif ce type d'URL: http://www.facebook.com/note/Scaling...ed-at-Facebook

C'est juste que les devs de facebook se sont pas emmerdés à faire de l'url-rewriting pour cette page là. A noter que PHP n'est pas un serveur web, il doit cohabiter avec Apache ou Nginx ou autre. C'est pas son job de faire des jolies urls... Alors que JEE pour la comparaison embarque tout, donc on parle naïvement du langage en parlant d'url-rewriting alors que ce n'est pas Java qui s'occupe de cela.

[Luckyluke34]

Franchement, est-ce bien utile de relayer les dires d'un monsieur qui est de parti pris jusqu'au bout des ongles dans l'affaire ?

C'est comme titrer une news affirmant qu'ASP .NET va triompher juste parce que Steve Ballmer l'a dit...

PHP s’imposera sur les serveurs face à Java et .NET

Le problème, c'est qu'avec un titre comme celui-là, le mec lambda qui passe se dira "wow, PHP est en train de regagner du terrain". Alors que pas du tout. La donne n'a absolument pas changé entre les acteurs du secteur.

Donc les guillemets ou la nuance n'auraient pas été superflus. Ou pourquoi ne pas titrer sur la critique contre Apple, comme le fait l'article original de VentureBeat (et c'est ça en réalité, la vraie news) ?

[Bluedeep]

Envoyé par alex_vino

Je n'ai pas une grane expérience en PHP donc je ne m'exprimerais pas sur la performance des projets d'envergure en PHP.
Par contre dans le lien que tu vient de donner on remarque que l'URL n'est pas tres jolie, par contre d'autres technologies génererait en natif ce type d'URL: http://www.facebook.com/note/Scaling...ed-at-Facebook

Je ne crois pas que ce soit la question de l'url ici qui est primordiale.

[Traroth2]

Envoyé par Grabeuh

Sachant qu'on va généralement passer par un serveur Memcache dans les deux cas si l'application est un tantinet sérieuse, je vois pas spécialement où tu veux en venir ?

Euh... non. Pour PHP, effectivement, la seule solution, c'est d'utiliser un cache externe comme Memcached. En Java, il y a des solutions de cache full-Java, comme EHCache ou Hazelcast.

[Bluedeep]

Envoyé par Luckyluke34

C'est comme titrer une news affirmant qu'ASP .NET va triompher juste parce que Steve Ballmer l'a dit...

Ben oui ...
et en faisant tourner un guéridon, l'esprit de Steve Jobs m'a informé que l'iPhone 18(dans sa version neuro-implémentée) sera en 2042 l'unique machine à tout faire.

ok,

[rawsrc]

Envoyé par Bluedeep

Ben oui ...
et en faisant tourner un guéridon, l'esprit de Steve Jobs m'a informé que l'iPhone 18(dans sa version neuro-implémentée) sera en 2042 l'unique machine à tout faire.

Déjà que le sujet de la news est trollesque...
Si tu en remets une couche, ça va partir en sucette pour de bon

[rimram31]

http://www.rubyinside.com/holiday-fu...ages-2911.html

[J_Lennon]

Envoyé par _skip

S'il y a bien en revanche un point sur lequel PHP semble s'approcher de Java, c'est la multiplication des gros ORM et gros framework usine à gaz qui font plein de magie noire.
Assez regrettable pour une techno qui se voulait souple et facile à prendre en main. J'ai mis mon nez dans pas mal de grosses plateformes ecommerce dernièrement, le genre qui tourne que sur un gros serveur, et je me suis vraiment demandé si on essayait pas de lui faire avaler n'importe quoi à ce pauvre PHP, d'en faire du J2EE dans le mauvais sens du terme.

surcouche pour plus de rigueur. Il y a des dérives mais c'est quand même un plus pour les gros projets...

[Grabeuh]

Envoyé par rimram31

Heu ... comparer APC a HotSpot, ça me laisse quelque peu perplexe ... ou s'est méconnaître les travaux réalisés dans les stratégies de compilation "à la volée", tout comme parler de memcache quand on peut utiliser tout simplement la mémoire de l'application avec toutes les possibilités offertes par le langage lui-même, ça me laisse aussi très dubitatif.

Ce sont plus des pansements collés sur une techno[...]

Pour une application de taille importante, tu as pratiquement toujours plusieurs serveurs en réplication avec un reverse proxy pour faire de l'équilibrage de charge.

Donc si tu stockes tes données directement dans la mémoire de ton application plutôt que sur un serveur Memcache, tu vas t'amuser à recalculer tes données pour chaque nouveau serveur qui doit traiter la même requête ? Tu vas interroger tous tes serveurs pour savoir lequel a la donnée ? Comment vas-tu gérer ta politique d'invalidation du cache si celui-ci est redondant ?

Après, Java possède probablement des outils équivalents à Memcache si vous voulez utiliser du Java partout, mais la problématique restent la même : partager le cache entre plusieurs serveurs. Car pour peu que l'appli à faire tourner soit importante, nécessite une disponibilité importante (banque en ligne, réseau social, site de vente) tu es pratiquement obligé d'avoir une architecture de ce type. Ne serait-ce que pour de la tolérance aux pannes.

Envoyé par alex_vino

Ajax est utilisé dans la plupart des applications et est une technologie plutot complémentaire au sujet. Quant aux flux de données c'est un élément externe dans un découpage de l'application et indépendant du coeur de ton application (du moins dans les regles de l'art) ce qui hors-sujet, sinon a cette allure tu est partie pour considérer le type de base de données aussi

Justement, c'est ni l'ajax ni le flux qui m'interessent ici, c'est le couple Ruby/Scala !
On voit bien que le coeur de leur application, la gestion et la mise en relation des tweets, sont issus d'une application Scala, qui tourne sur une JVM.
Là dessus, ils auraient pu profiter de l'architecture existante et faire l'interface du site en Java ou un autre langage JVM pour rentabiliser l'infrastructure et les développeurs.
Mais ils ont préféré utiliser Ruby et son framework Rails pour générer l'interface, car ça devait probablement leur apporter un confort lors du développement.

Après, que ça soit un flux lu en Ajax ou un appel SOAP ou XML-RCP sur l'application principale, j'ai envie de dire qu'on s'en tamponne un peu, ça c'est la manière d'interconnecter les parties entre elles. Idem pour le type de base de données.

Ce que je voulais faire remarquer, c'est qu'ils font coexister deux technos différentes sur un même projet : Ruby et JVM. Ca aurait pu être un couple PHP/.NET, ou Python/Haskell, ou Perl/COBOL ça aurait été la même chose.

C'était en réaction à l'affirmation suivante, qui pour moi est totalement fausse :

on ne mélange pas du PHP / .Net / Ruby / Java / Python dans un meme projet

[EDIT parce que c'est trop drôle et que je veux pas faire de double post]

Envoyé par smetairie

Bonjour

tout de meme certains commentaires au dessus sont aussi "pertinents" que ce qu'affirme le mec de Zend.

Dire que Java est un effet de mode, c'est assez ahurissant, avec 20% de part de marché ! Je sais meme pas si PHP a 5% ?

Scala, Clojure, Play et autres languages en bytecode JVM sont encore confidentiels à ce jour pour détecter une tendance.

Server-side Programming Languages

Most popular server-side programming languages
© W3Techs.com usage change since
1 September 2012
1. PHP 78.3% +0.3%
2. ASP.NET 20.8% -0.4%
3. Java 4.0%
4. ColdFusion 1.1% -0.1%
5. Perl 0.9%
percentages of sites

source: http://w3techs.com/

[miboo]

sur quelle base peut on dire que PHP est plus "performant" que java ? Je ne lance pas un troll, j'aimerai juste comprendre.

[camus3]

Most popular server-side programming languages
© W3Techs.com usage change since
1 September 2012
1. PHP 78.3% +0.3%
2. ASP.NET 20.8% -0.4%
3. Java 4.0%
4. ColdFusion 1.1% -0.1%
5. Perl 0.9%
percentages of sites

Ce classement ne veut pas dire grand chose. Le serveur le plus déployé est bien sur Linux(...)/Apache, et PHP tourne en général dessus.

Il serait plus intéressant de calculer à une date D combien de projets sont commencés sous Java , Ruby , Python , .NET ou PHP , dans quel domaine et avec quel budget.

Je ne suis pas sur que PHP soit dans le haut de pavé.

Et nombre de personnes utilisant php le font uniquement pour déployer un CMS, on ne peut pas appeler cela du développement.

[camus3]

Envoyé par rimram31

http://www.rubyinside.com/holiday-fu...ages-2911.html

Tu m'as tué avec ce lien

[alex_vino]

Envoyé par Grabeuh

Most popular server-side programming languages
© W3Techs.com usage change since
1 September 2012
1. PHP 78.3% +0.3%
2. ASP.NET 20.8% -0.4%
3. Java 4.0%
4. ColdFusion 1.1% -0.1%
5. Perl 0.9%
percentages of sites

source: http://w3techs.com/

Déja l'auteur de ces chiffres ne sais pas que ASP.Net n'est pas un language, donc je me doute de la véracité de ces chiffres
@camus3 a raison a ces propos.

[Bluedeep]

Envoyé par alex_vino

Déja l'auteur de ces chiffres ne sais pas que ASP.Net n'est pas un language.

Là, c'est un peu de la mauvaise foie Au contraire, ça a le mérite de regouper la techno web .net sous une seule et même ligne sans distinction du langage, distinction qui, dans le cas de asp.net, n'a pas beaucoup de pertinence (problème ne se posant pas avec les technos Php et Java).

[Grabeuh]

Envoyé par camus3

Ce classement ne veut pas dire grand chose. Le serveur le plus déployé est bien sur Linux(...)/Apache, et PHP tourne en général dessus.

Il serait plus intéressant de calculer à une date D combien de projets sont commencés sous Java , Ruby , Python , .NET ou PHP , dans quel domaine et avec quel budget.

Je ne suis pas sur que PHP soit dans le haut de pavé.

Justement, le site cité en source fonctionne sur ce principe : PHP observe la plus grosse progression avec 63 nouveaux projets répertoriés depuis le 1er septembre, contre aucun pour Java.

Après, ceci est aussi probablement lié à la culture PHP où l'on a la facheuse manie de réinventer la roue des centaines de fois avec très peu d'innovation à chaque fois.

Et nombre de personnes utilisant php le font uniquement pour déployer un CMS, on ne peut pas appeler cela du développement.

Ce n'est certes pas du développement spécifique, mais ça reste une utilisation du langage.
Si le besoin est commun, et qu'une application existe déjà pour répondre à ce besoin, pourquoi aller voir ailleurs et faire faire un développement spécifique dans un autre langage ?

C'est ça aussi qui rend un langage attrayant : son écosystème, les applications clé en main et les bibliothèques qu'il propose par rapport aux besoins que tu as pour un projet donné.

Et puis je trouve ça étonnant cet argument "les CMS ça compte pas".
Il a bien fallu le développer, il faut le maintenir, ça représente des communautés de centaines de personnes et d'entreprises qui investissent dedans. Ca représente aussi un écosystème avec des plugins développés tous les jours par des développeurs spécialisés Drupal/Wordpress/Joomla/autres.
Ne pas le prendre en compte dans les utilisations du langage, c'est un peu nier l'investissement nécessaire à la création de cet outil ?

Envoyé par bluedeep

Au contraire, ça a le mérite de regouper la techno web .net sous une seule et même ligne sans distinction du langage, distinction qui, dans le cas de asp.net, n'a pas beaucoup de pertinence (problème ne se posant pas avec les technos Php et Java).

Complètement d'accord avec toi sur ce point.

[rimram31]

Envoyé par Grabeuh

Pour une application de taille importante, tu as pratiquement toujours plusieurs serveurs en réplication avec un reverse proxy pour faire de l'équilibrage de charge.

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). Ajoutes-y tout ce que tu pourras mettre en mémoire au niveau applicatif, d'un module, une requête, une servlet ... et a peu près tout ce qui te chante tout en collant "naturellement" a ton architecture et la nature de ton trafic.

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.

[alex_vino]

Envoyé par Bluedeep

Là, c'est un peu de la mauvaise foie Au contraire, ça a le mérite de regouper la techno web .net sous une seule et même ligne sans distinction du langage, distinction qui, dans le cas de asp.net, n'a pas beaucoup de pertinence (problème ne se posant pas avec les technos Php et Java).

Oui c'est bien de regrouper C#/VB, mais le titre est completement faux.

[rimram31]

Envoyé par Grabeuh

Server-side Programming Languages

Most popular server-side programming languages
© W3Techs.com usage change since
1 September 2012
1. PHP 78.3% +0.3%
2. ASP.NET 20.8% -0.4%
3. Java 4.0%
4. ColdFusion 1.1% -0.1%
5. Perl 0.9%
percentages of sites

source: http://w3techs.com/

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" car adapté a une clientèle non spécialiste pour faire "quelques bricoles" (en général) et facile a mutualiser contrairement a du Java par exemple. Toutefois 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.