Statistiques de versions de PHP - janvier 2013

Par Pascal MARTIN le - Lien permanent 10 commentaires

Quelques cinq mois après le dernier article de cette série, publié en août 2012, voici un nouvel état des lieux des différentes versions de PHP et de leur utilisation sur Internet — à titre de comparaison, vous voudrez peut-être aussi jeter un coup d’œil à l’article que j’avais publié il y a un an, en janvier 2012.

Les données présentées dans cet article ont été collectées le week-end du 12 janvier 2013. Les versions stables de PHP sont PHP 5.3.20 et PHP 5.4.10 qui ont été publiées le 20 décembre 2012 ; cela fait tout juste deux ans que PHP 5.2 n’est plus supportée ; et la 3ème version alpha de PHP 5.5 a été publiée il y a quelques jours.

Sommaire :


Quelques mots sur la méthode

Pour faire simple1, j’ai récupéré une liste de plus de 9.4 millions de noms de domaines, issus principalement :

  • Du top 1 million d’Alexa (chargé plusieurs fois à quelques semaines/mois d’écart sur l’année et demie écoulée, ce qui donne maintenant nettement plus de 1 million de noms de domaines),
  • Des liens externes de wikipedia de plusieurs langues (environ 3 millions de noms de domaines),
  • De l’export mis à disposition par l’Export Open Directory (environ 2 millions de noms de domaines, certains correspondant à des sites un peu anciens et pas vraiment mis à jour),
  • Et de quelques résultats de recherche google (quelques milliers de noms de domaines).

Ensuite, pour chacun de ces noms de domaines, j’ai effectué une requête HTTP HEAD sur domaine.tld, en me rabattant sur www.domaine.tld si la première requête échouait.

Après cela, je me suis généralement2 basé sur l’en-tête HTTP X-Powered-By renvoyée par le serveur, pour en extraire le nom de logiciel ayant servir à générer la page, ainsi que sa version.
Et dans le cas où cette en-tête n’existe pas, ou ne contient pas d’information exploitable, je me suis rabattu sur l’en-tête Server.

Pour rappel, et en ne prenant que quelques exemples relativement typiques, les en-têtes HTTP renvoyées par le serveur, dans le cas de pages générées par PHP et sur un serveur exposant la version de PHP utilisée, ressemblent souvent à quelque chose de ce type (pour www.php.net) :

Server: Apache/2.2.21 (FreeBSD) mod_ssl/2.2.21 OpenSSL/0.9.8q PHP/5.4.11-dev
X-Powered-By: PHP/5.4.11-dev

ou (pour drupal.org) :

Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.16

A partir de là, extraire le numéro de la version de PHP utilisée est une opération relativement aisée…


Quelques chiffres

Réponses PHP

Sur les 8.7 millions de requêtes HTTP effectuées sur les noms de domaines que j’ai testé, environ 26% des réponses ont été identifiées comme générées par du PHP.

Plus précisément, j’ai identifié 2,228,529 réponses comme correspondant à du PHP.

Avec ce nombre relativement conséquent de réponses, les statistiques présentées plus bas devraient avoir des chances d’être à peu près correctes, ou, tout au moins, de donner des résultats et chiffres relativement proches de la réalité…


Serveurs Web

Cela dit, avant d’entrer dans les détails des versions de PHP, voici la liste des Serveurs Web les plus fréquemment identifiés lors de ma collecte de données :

  • Apache : 5,164,189 — 66.07%
  • IIS : 1,377,796 — 17.63%
  • nginx : 554,345 — 7.09%
  • Autres : 367,593 — 4.70%
  • GSE : 190,096 — 2.43%
  • LiteSpeed : 63,995 — 0.82%
  • YTS : 55,838 — 0.71%
  • Oversee Turing v1.0.0 : 42,196 — 0.54%

Ou, sous forme d’un graphe :

Serveurs Web

On ne constate pas de véritable révolution par rapport aux données collectées il y a cinq mois ou il y a un an :

  • Apache, toutes versions confondues, reste encore très loin devant tous les autres, servant deux tiers des pages interrogées — mais perd quelque chose comme 1.7 point en un an,
  • IIS conserve sa seconde place — en perdant 1 point en un an,
  • Et nginx est encore en troisième place — en ayant gagné plus de 1.5 point en un an.


Versions majeures de PHP

Commençons par les versions majeures de PHP, en prenant en compte les résultats qui ont été identifiés comme correspondant à une version supérieure ou égale à 3, et inférieure ou égale à 63.

Mes tests ont remonté le nombre suivant de domaines sur chaque version majeure de PHP :

  • PHP 3 : 648 — 0.03%
  • PHP 4 : 191,521 — 8.59%
  • PHP 5 : 2,036,247 — 91.38%
  • PHP 6 : 17 — 0.00%

Sous forme d’un graphe, qui peut être plus parlant pour certains et permet de voir en un clin d’œil quelle est la version majeure de PHP la plus répandue, cela donne :

Versions majeures de PHP

On notera :

  • Que, fort heureusement, PHP 5 est la version majeure la plus répandue ; PHP 5 passe d’ailleurs pour la première fois au-dessus des 90%,
  • Mais que, début 2013, on a encore quelques centaines de sites, sur 8.7 millions, qui tournent encore sur du PHP 3,
  • Et aussi que PHP 4 est encore vraiment trop répandue, alors que cela fait des années que cette version n’est plus du tout maintenue (PHP 4.4.9, publiée en Août 2008, était annoncée comme étant la dernière version de PHP 4.x),
  • Et enfin que, bientôt trois ans après la mise à mort de la branche PHP 6 (qui, pour rappel, n’a jamais vu une version ne serait-ce qu’alpha être publiée), on rencontre (encore) des sites qui utilisent PHP 6 en production ???


Versions mineures de PHP

Si on passe aux versions mineures de PHP, toujours pour PHP >= 3.x et PHP <= 6.x, et en ne conservant que les versions qui sont remontées 10 fois ou plus, on obtient les données suivantes :

  • PHP 3.0 : 646 — 0.03%
  • PHP 4.0 : 1,469 — 0.07%
  • PHP 4.1 : 3,434 — 0.15%
  • PHP 4.2 : 3,133 — 0.14%
  • PHP 4.3 : 40,804 — 1.83%
  • PHP 4.4 : 142,681 — 6.40%
  • PHP 5.0 : 5,085 — 0.23%
  • PHP 5.1 : 69,958 — 3.14%
  • PHP 5.2 : 1,014,151 — 45.51%
  • PHP 5.3 : 910,630 — 40.86%
  • PHP 5.4 : 36,410 — 1.63%
  • PHP 6.0 : 17 — 0.00%

Et sous forme graphique :

Versions mineures de PHP

Pour résumer :

  • PHP 5.2, qui a atteint sa fin de vie en décembre 2010, il y a deux ans, est encore la version de PHP qui semble aujourd’hui la plus utilisée / répandue — mais les choses vont dans le bon sens, puisque PHP 5.2 est pour la première fois passée sous la barre des 50% ! (51.42% en août 2012, et 62.35% en janvier 2012)
  • PHP 5.3, stable depuis juin 2009, soit trois ans et demi, n’arrive toujours qu’en seconde place — mais continue à se rapprocher de la première, et va probablement bientôt l’atteindre,
  • PHP 5.4, dont la première version stable a été publiée le 1er mars 2012, monte tout doucement en puissance, puisqu’elle ne représente que 1.63% des installations comptabilisées.
  • Pour la petite histoire : cela ne se voit pas ici, mais j’ai identifié 8 serveurs en PHP 5.5.0 (un en -alpha1, un en -alpha3, et les autres en -dev)

On peut donc dire que PHP 5.3 s’est enfin imposée !

Pas trop tôt devrais-je dire, puisqu’il est fort probable que PHP 5.3 atteigne bientôt sa fin de vie — peut-être au moment de la sortie de PHP 5.5, qui pourrait avoir lieu au printemps… Autrement dit, si, en 2013, vous êtes encore avec une version <= 5.2, il n’est plus temps de passer à PHP 5.3, mais bel et bien à 5.4 ;-)

Et il peut aussi être temps de commencer à vous pencher sur PHP 5.5, qui propose plein de nouveautés intéressantes, et est actuellement en phase de versions alpha.


Versions releases de PHP

Et enfin, si on descend au niveau des versions release de PHP 5.x4, en ne conservant que les versions qui remontées 100 fois ou plus, on obtient les données suivantes :

  • Pour PHP 5.0 :
    • 5.0.1 : 107 — 0.01%
    • 5.0.2 : 236 — 0.01%
    • 5.0.3 : 527 — 0.03%
    • 5.0.4 : 3,428 — 0.17%
    • 5.0.5 : 763 — 0.04%
  • Pour PHP 5.1 :
    • 5.1.1 : 265 — 0.01%
    • 5.1.2 : 4,486 — 0.22%
    • 5.1.3 : 1,601 — 0.08%
    • 5.1.4 : 1,785 — 0.09%
    • 5.1.5 : 204 — 0.01%
    • 5.1.6 : 61,603 — 3.03%
  • Pour PHP 5.2 :
    • 5.2.0 : 16,866 — 0.83%
    • 5.2.1 : 4,587 — 0.23%
    • 5.2.2 : 1,313 — 0.06%
    • 5.2.3 : 5,774 — 0.28%
    • 5.2.4 : 34,101 — 1.67%
    • 5.2.5 : 25,145 — 1.23%
    • 5.2.6 : 124,980 — 6.14%
    • 5.2.7 : 184 — 0.01%
    • 5.2.8 : 17,303 — 0.85%
    • 5.2.9 : 54,962 — 2.70%
    • 5.2.10 : 33,994 — 1.67%
    • 5.2.11 : 21,099 — 1.04%
    • 5.2.12 : 28,176 — 1.38%
    • 5.2.13 : 31,587 — 1.55%
    • 5.2.14 : 36,442 — 1.79%
    • 5.2.15 : 3,137 — 0.15%
    • 5.2.16 : 11,545 — 0.57%
    • 5.2.17 : 562,822 — 27.64%
    • 5.2.185 : 113 — 0.01%
  • Pour PHP 5.3 :
    • 5.3.0 : 2,522 — 0.12%
    • 5.3.1 : 3,310 — 0.16%
    • 5.3.2 : 52,101 — 2.56%
    • 5.3.3 : 208,429 — 10.24%
    • 5.3.4 : 3,574 — 0.18%
    • 5.3.5 : 24,212 — 1.19%
    • 5.3.6 : 78,797 — 3.87%
    • 5.3.7 : 590 — 0.03%
    • 5.3.8 : 57,818 — 2.84%
    • 5.3.9 : 8,071 — 0.40%
    • 5.3.10 : 89,158 — 4.38%
    • 5.3.11 : 904 — 0.04%
    • 5.3.12 : 552 — 0.03%
    • 5.3.13 : 33,792 — 1.66%
    • 5.3.14 : 21,402 — 1.05%
    • 5.3.15 : 50,011 — 2.46%
    • 5.3.16 : 32,741 — 1.61%
    • 5.3.17 : 34,282 — 1.68%
    • 5.3.18 : 115,808 — 5.69%
    • 5.3.19 : 56,717 — 2.79%
    • 5.3.20 : 35,831 — 1.76%
  • Pour PHP 5.4 :
    • 5.4.0 : 983 — 0.05%
    • 5.4.1 : 140 — 0.01%
    • 5.4.3 : 1,452 — 0.07%
    • 5.4.4 : 4,115 — 0.20%
    • 5.4.5 : 1,413 — 0.07%
    • 5.4.6 : 3,749 — 0.18%
    • 5.4.7 : 3,832 — 0.19%
    • 5.4.8 : 3,340 — 0.16%
    • 5.4.9 : 5,914 — 0.29%
    • 5.4.10 : 11,384 — 0.56%

Et sous forme graphique :

Versions releases de PHP

Pour résumer :

  • Toujours une quantité non-négligeable (3.03%) de sites sous PHP 5.1.6 (qui a été publiée en Août 2006) ; la version fournie par défaut sous certaines distributions, il me semble, genre Redhat Enterprise.
  • Beaucoup de PHP 5.2.6 (6.14%) (publiée en Mai 2008) ; la version fournie par défaut sous Debian Lenny, par exemple.
  • La version de PHP la plus répandue est PHP 5.2.17 (publiée en Janvier 2011), avec 27.64% ; ça reste du 5.2, qui a atteint sa fin de vie, mais positivons, en se disant que c’est la dernière version, la plus à jour…
  • Et enfin, plusieurs sous versions de PHP 5.3.x, sans qu’aucune ne s’impose vraiment ; entre autres :
    • PHP 5.3.3, qui est la version 5.3.x la plus représentée avec 10.24% — la version par défaut sous Debian Squeeze, notamment,
    • PHP 5.3.10 (4.38%) — version par défaut sous Ubuntu 12.04 (qui est une LTS — dommage, les 6 versions de retard), par exemple.

Pour PHP 5.3 et 5.4, hormis les versions fournies par quelques grandes distributions, on constate qu’aucune version ne s’impose réellement, et que toutes se partagent une petite part des serveurs installés ; si je devais me risquer à une interprétation, je dirais que les hébergeurs ont du mal à suivre le rythme de publication des mises à jour, qui tourne depuis quelques temps à une nouvelle version par mois (l’idée étant, bien entendu, de publier plus rapidement les corrections de bugs).


Evolution

Je ne ferai pas une longue analyse sur le pourquoi du comment des chiffres que j’ai présenté ici : libre à vous de commenter sur le trop grand usage de versions complètement obsolètes, et le manque de mise à jour que l’on peut, malheureusement, trop souvent constater…

Cela dit, puisque ce n’est pas la première fois que j’effectue ce processus de collecte de statistiques à propos des versions de PHP utilisées, je me suis dit qu’il pouvait être intéressant de tracer un graphe représentant l’évolution de ces utilisations.

Le graphe reproduit ci-dessous présente donc l’évolution de l’utilisation des versions mineures de PHP, depuis septembre 20116 :

Evolution de l'utilisation des versions (mineures) de PHP

J’ai essayé de mettre en évidence les versions les plus à même de nous concerner en ce moment (à savoir, PHP 5.2, 5.3, et 5.4), ainsi que, dans une moindre mesure les deux autres versions les plus utilisées (autrement dit, PHP 4.4 et 5.1).

Je disais dès avril 2012 que PHP 5.2 laissait petit à petit sa place à PHP 5.3, et en août 2012 que c’était encore plus visible quelques mois plus tard… Nous en sommes désormais au point où PHP 5.3 a quasiment rattrapé PHP 5.27 !

Maintenant, à nous de faire en sorte que PHP 5.4 soit adopté plus rapidement que PHP 5.3 ne l’a été — PHP 5.3 semblant être sur le point d’atteindre sa fin de vie, et la migration 5.3 -> 5.4 représentant un pas moins important que celui séparant PHP 5.2 de 5.3.


  1. Oui, il y a beaucoup de copier-coller d’article en article, pour cette section “méthode” : elle ne change pas d’une fois à l’autre. ↩

  2. Pour certains types de serveurs ou de logiciels, j’ai mis en place un bout de code qui va chercher les informations de version dans d’autres en-têtes que X-Powered-By. Par exemple, pour les sites développés en ASP.NET, les informations de version figurent généralement dans une en-tête nommée X-AspNet-Version. ↩

  3. Pour ne pas prendre en compte les quelques résultats abherrant qu’on aurait pu relever. ↩

  4. PHP 4 correspondant à des versions tellement dépassées que je préfére ne pas prendre la peine de rentrer au niveau des versions release. ↩

  5. Oui, j’ai trouvé des serveurs indiquant qu’ils utilisaient une version 5.2.18 de PHP — alors qu’il n’existe pas “officiellement” de version 5.2.18.
    En pratique, la version indiquée est généralement PHP/5.2.18-dev (sur snowfactory.fi par exemple ; ce suffixe -dev correspond typiquement à un build depuis les sources de la branche 5.2 de PHP), ou PHP/5.2.18-edong (sur damophoto.com par exemple ; pour ce suffixe -edong, aucune idée de son origine ; je ne me rappelle pas l’avoir vu auparavant — possiblement un hébergeur qui fait ses propres build de PHP ?) ↩

  6. Les chiffres présentés sur le graphique d’évolution sont en pourcentages, afin d’être indépendants du nombre d’hôtes interrogés, qui varie à chaque série de collectes. ↩

  7. J’ai bon espoir de pouvoir annoncer, la prochaine fois où je publierai un article de cette série, que PHP 5.3 aura dépassé PHP 5.2, et sera alors en première place ;-) ↩

Vous avez apprécié cet article ? Faites le savoir !

Les posts suivants pourraient aussi vous intéresser :

Commentaires

1. Par Julien Breux le 2013-01-14 10:59
Julien Breux

Hébergeurs & distribs… quand tu nous tiens…

2. Par Remi le 2013-01-14 14:15
Remi

Toujours une quantité non-négligeable (3.03%) de sites sous PHP 5.1.6 (qui a été publiée en Août 2006) ; la version fournie par défaut sous certaines distributions, il me semble, genre Redhat Enterprise.

Petites précisions:

php 5.1.6 est la version par défaut sous RHEL 5 (et donc CentOS 5) mais qui fournit aussi php 5.3.3

php 5.3.3 est la version par défaut sous RHEL-6

Cela explique sans doute les ~10% de cette version.

Remarque : bien qu’il s’agisse d’une version pouvant sembler ancienne, elle est maintenue et les correctifs de sécurité (et certains autres) sont rétro portés.

3. Par Pascal MARTIN le 2013-01-14 20:33
Pascal MARTIN

@Julien Breux > yep ^^ ; après, j’admets le premier qu’il n’est pas “facile” de monter de version : ça demande d’y passer du temps (et de l’argent, donc) pendant lequel ceux qui s’occupent de cette montée de version ne bossent pas sur autre chose… le tout pour un gain qui n’est pas évident aux yeux d’un décideur “non-technique”.

Et pour les hébergeurs, effectuer de par eux-même une montée de version susceptible d’entrainer des problèmes sur les sites de leurs clients (qui n’ont rien demandé, la plupart du temps — ceux qui veulent être à jour prenant un serveur dédié qu’ils administrent aux-même), on ne peut nier la part de risque — je ne suis aucunement surpris du fait qu’ils ne fassent pas ce type de migration.

@Remi > Ok, merci pour ces précisions !

Que les corrections soient rétro-portées est une bonne chose (ça évite des serveurs plein de trous, sans apporter trop de risque avec des nouvelles versions introduisant de nouvelles fonctionnalités ou changements) ; en même temps, est-ce que ce n’est pas un peu “piègeux” pour les utilisateurs, qui croient disposer d’une version de PHP, alors qu’ils sont au final sur une sorte d’hybride à cheval sur plusieurs versions ?

Et rester sur une branche 5.3 avec des corrections issues de versions 5.3.x plus récentes signifie tout de même ne pas disposer des évolutions apportées par les versions suivantes.

4. Par Remi le 2013-01-15 10:49
Remi

Oui c’est un peu ambigu (plutôt que piégeux) et il faut régulièrement l’expliquer aux utilisateurs.

Mais c’est le seul moyen de fournir une API/ABI stable aux utilisateurs (ce qui est l’un des raison d’être des distributions “entreprise”). Et surtout, cela n’empêche pas de découvrir de nouveaux bugs, de les corriger et d’appliquer les corrections upstream.

Maintenant, je suis personnellement un adepte de la progression “à petits pas” (chaque version mineure) plutôt que des grands sauts (genre 5.1.6 => 5.4.10…)

J’ai d’ailleurs arrêté le support de la 5.3 dans mon dépôt.

Et je travaille déjà activement au passage en 5.5 (en remontant pas mal de propositions de correctifs à différents projets).

Pour mémoire, je pense que le retard de la disponibilité de certaines extensions a été un frein à l’adoption de la 5.4 (ce qui, j’espère, ne se reproduira pas avec la 5.5), ainsi que du manque de compatibilité affichée par certains gros projets. Maintenant, le taux de 5.2 me laisse… comme dire… pantois ?

5. Par Pascal MARTIN le 2013-01-15 21:20
Pascal MARTIN

@Remi > Effectivement, rester sur quelque chose de stable répond plutôt bien aux besoins que je constate dans le milieu pro ; et je le comprends tout à fait — même si ce n’est pas vraiment ce que j’aimerais, en tant que développeur ^^

L’arrêt du support de PHP 5.3 sur ton dépôt, ça m’intéresse, merci pour le lien ; j’en prend note, ça pourrait me servir un jour : je suis nettement plus “développeur” que “admin sys” ou approchant (même si j’ai quelques notions d’admin — ça aide à comprendre ce qu’il se passe autour de mon code ^^) et je suis plus “debian” que “redhat” (désolé ^^ ), mais je sens que ça pourrait me servir pour encourager quelques migrations supplémentaires ;-)

Pour ce qui est du manque de support / compatibilité de certaines extensions avec PHP 5.4, je suis tout à fait d’accord avec toi : il y a des extensions (je pense notamment à APC, qui avait jusqu’à il y a encore peu de temps la réputation de ne pas trop fonctionner avec PHP 5.4) sans lesquelles il n’est pour ainsi dire pas envisageable de déployer certains sites.

Quant à la non-compatibilité affichée par certains projets… même si les projets en eux-même sont capables de supporter une version de PHP plus récente au niveau de leur cœur, j’ai peur qu’il n’en soit trop souvent pas de même pour un nombre conséquent de plugins / extensions / modules, qui ne sont pas toujours aussi bien maintenus / testés que le core du projet.

6. Par Fnux le 2013-01-21 17:17
Fnux

Bonjour,

Merci pour cette étude, mais vos chiffres me semblent un peu confus.

En effet, vous dites avoir récolté 9.4 millions de noms de domaines.

Puis vous dites aussi avoir effectué 8.7 millions de requêtes HTTP.

Quels sont donc les 700.000 noms de domaines non testés et pourquoi ?

Ensuite, en additionnant les chiffres du nombre de serveurs que vous relevez, on arrive à un total de 7.816.048.

Soit 900.000 de moins que les 8.7 millions de requêtes.

Là encore, pourquoi un tel écart ?

Enfin, vous donnez un chiffre de 2.228.529 réponses correspondant à des sites PHP.

Soit 23.70 % du nombre des 9.4 millions de noms de domaine, ou 25.61 % du nombre des 8.7 millions de requêtes, ou encore 28.51 % du nombre des 7.8 millions de serveurs.

Mon propos n’est pas de contester vos chiffres mais simplement de mieux les comprendre.

Ensuite, il serait particulièrement intéressant d’avoir une statistique un peu plus fine faisant apparaître le pourcentage du nombre de sites PHP par type de serveur.

Exemple :

Apache : 5.164.189 dont x en PHP, IIS : 1.377.796 dont y en PHP, Nginx : 554.345 dont z en PHP, etc.

Cela permettrait de mieux appréhender l’utilisation de PHP par type de serveur car je doute sérieusement que les chiffres de l’usage de PHP avec Apache ou Ngnix soit du même ordre que celui avec IIS. ;=)

La question qui me vient ensuite à l’esprit est :

Si entre 23 et 28 % (je ne vais pas chipoter sur le bon pourcentage à utiliser) des sites utilisent PHP, quels autres langages sont donc alors utilisés par le reste des sites interrogés qui représentent une très sérieuse majorité, soit entre 72 et 77 %.

Merci d’une éventuelle précision.

PS: Une étude réalisée par Verisign et publiée en 2011 noms de domaine relevait qu’il existait plus de 210 millions de noms de domaine à fin Q1 2011 et une autre réalisée par l’AFNIC à la même période domaine . fr annonçait que le nombre de sites en .fr avait passé le cap des 2 millions, se plaçant ainsi au 15ème rang mondial, loin derrière les 85 millions de sites .com et les 25 millions de sites .net.

7. Par Pascal MARTIN le 2013-01-21 20:37
Pascal MARTIN

@Fnux > Merci pour votre commentaire ; il est vrai que je n’ai jamais explicité “autant que possible” les différents chiffres ainsi que la manière dont je les obtenais, et leur signification les uns par rapport aux autres ; j’espère que les quelques lignes ci-dessous (en voulant relire avant de poster, je me rend compte que j’ai pondu un roman ; et que ça fait un bon moment que j’y suis ^^ ) répondront — au moins en partie — à vos interrogations, et permettront d’éclairer un peu tout ça.


En effet, vous dites avoir récolté 9.4 millions de noms de domaines.

Le nombre de noms de domaines (9.4M ce coup-ci) correspond à mon “point d’entrée” : des noms de domaines (récupérés d’alexa, wikipedia, quantcast que j’ai honteusement oublié de citer dans cet article, …).
Autrement dit, au départ, au moment où je me dis “je vais collecter les données pour en faire des stats”, tout ce que j’ai c’est une liste de noms de domaines.


Quels sont donc les 700.000 noms de domaines non testés et pourquoi ?

A partir de cette liste de noms de domaines, j’effectue une résolution DNS (je cherche à obtenir l’adresse IP correspondant à chaque nom de domaine).

Pour la majeure partie des noms de domaine, cette résolution DNS est réussie ; les noms de domaine + IP correspondante peuvent alors passer à l’étape d’après.

Mais pour une partie des noms de domaine (les 700,000 de ce coup-ci), la résolution DNS échoue : je ne trouve pas d’IP correspondant au nom de domaine. Ce peut-être parce que le nom de domaine est vieux et n’existe plus, parce que j’ai des entrées invalides dans ma liste de noms de domaine, … Quoi qu’il en soit, si je ne parviens pas à effectuer la résolution DNS, les noms de domaine correspondant (de l’ordre de 700,000 ce mois-ci) ne passent pas à l’étape suivante.


Puis vous dites aussi avoir effectué 8.7 millions de requêtes HTTP.

Pour chaque nom de domaine pour lequel j’ai une adresse IP, j’effectue une requête HTTP ; d’où les 8.7 M (les 8.7 M = 9.4 M - 700 k de “résolution DNS échouée”) requêtes HTTP.


Ensuite, en additionnant les chiffres du nombre de serveurs que vous relevez, on arrive à un total de 7.816.048.
Soit 900.000 de moins que les 8.7 millions de requêtes.
Là encore, pourquoi un tel écart ?

Je vois deux raisons à cela :

  • La première est que toutes les requêtes HTTP ne réussissent pas : une partie de ces requêtes échoue (soit parce que le serveur à l’autre bout est tombé / hors-ligne / injoignable au moment où je fais la requête, soit parce qu’il ne répond pas assez vite, soit parce que la requête ou la réponse s’est “perdue”) — ça ne concerne qu’une petite partie des requête : j’en ai 8,666,448 qui sont marquées comme ayant réussies.
  • La seconde est que, pour construire la liste des serveurs que je présente dans cet article, je ne tiens compte que des réponses HTTP pour lesquelles j’ai reçu / identifié une information de serveur (les réponses pour lesquelles j’ai eu une en-tête Server ; dont j’ai réussi à extraire une information). Mais aussi (j’avoue, j’ai été relire mes scripts, et je ne me souvenais plus de cette partie), je ne tiens compte que des noms de serveurs remontés plus de 100 fois — j’aurais pu en tenir compte, mais, quand j’ai écrit ce script, j’ai dû vouloir m’assurer de ne pas avoir de donnée “bizarre” (au sens truc complétement tordu qui n’est utilisé nulle part) qui vienne “polluer”.

Par rapport au second point, une requête dans ma DB m’indique 815k domaines pour lesquels j’ai eu une réponse “réussie”, mais pour lesquels je n’ai pas d’information “Serveur”.


vous donnez un chiffre de 2.228.529 réponses correspondant à des sites PHP.
Soit 23.70 % du nombre des 9.4 millions de noms de domaine, ou 25.61 % du nombre des 8.7 millions de requêtes, ou encore 28.51 % du nombre des 7.8 millions de serveurs.

Pour calculer ce pourcentage :

  • Je commence par compter le nombre de noms de domaines pour lesquels j’ai noté “PHP”,
  • Ensuite, je compte le nombre de noms de domaines pour lequels j’ai obtenu une réponse “réussie” (totalement indépendamment de l’information “Serveur”, que je n’utilise que dans la section “Serveurs Web” de mon article ; indépendamment aussi du fait d’avoir ou non obtenu une information de langage / techno),
  • Et je divise le premier nombre par le second.

Cela correspond donc presque à votre seconde proposition ; mis à part que je tiens compte du nombre de réponses obtenues avec succès, et pas du nombre de requêtes — le premier étant assez proche du second (ça fait aussi 8.7 M).


Ensuite, il serait particulièrement intéressant d’avoir une statistique un peu plus fine faisant apparaître le pourcentage du nombre de sites PHP par type de serveur.
[…]
Cela permettrait de mieux appréhender l’utilisation de PHP par type de serveur car je doute sérieusement que les chiffres de l’usage de PHP avec Apache ou Ngnix soit du même ordre que celui avec IIS. ;=)

En fait, lorsque je collecte les données que j’utilise pour ce type d’article, je cherche à répondre à une question : “quelle est la version de PHP que je peux utiliser ?”.
(Historiquement, quand j’ai pour la toute première fois collecté ce type de données / stats, la vraie question était “est-ce que je peux réussir à pousser une bascule vers PHP 5.3 ?”)

Ca se décline bien entendu en plusieurs sous-questions, et ça a plusieurs buts :

  • Montrer qu’une version de PHP donnée est suffisament répandue pour pouvoir être requise pour un type de projet donné (je pense par exemple à certains projets open-source, qui peuvent considérer que si, aujourd’hui, PHP 5.3 correspond en gros à 40%, alors, ils peuvent avoir cette version comme pré-requis).
  • Montrer qu’une version “récente” de PHP est utilisée par beaucoup de monde — et qu’il y a donc des chances qu’elle soit suffisamment stable pour être utilisée en production ; y compris sur des projets de taille conséquente.
  • Ajouter du poids quand je dis “hou hou, la version X.Y de PHP, elle est vraiment dépassée ; quand est-ce qu’on passe à une version plus sympa ?” (et, en fonction de la version, pour laquelle il y a des corrections de bugs / problèmes de sécurité)

Avoir une statistique plus fine, remontant l’utilisation de PHP par type de serveur, ne m’intéresse, moi personnellement, pas : ce n’est pas un besoin que j’ai (au départ, ces collectes de données et analyses, je les faisais purement pour moi ; pour pouvoir dire autour de moi “PHP 5.3 est là, et si on passait à PHP 5.3” — c’était un petit moment avant que je ne me dise que ça pouvait en intéresser d’autres et que je ne publie ces articles ; malheureusement, je n’ai pas conservé les résultats) — et descendre dans des statistiques plus fines veut aussi dire donner plus de poids aux erreurs et imprécisions ;-)

Cela dit, je note la suggestion ; peut-être que, un jour… ;-)


quels autres langages sont donc alors utilisés par le reste des sites interrogés qui représentent une très sérieuse majorité, soit entre 72 et 77 %

La réponse qui me vient à l’esprit (désolé si c’est un peu brutal) est “ça ne m’intéresse pas, ce n’est pas la question que je me pose”.

En pratique : je n’ai pas vraiment cherché à savoir ; et autant je sais avec un niveau de confiance pas trop mauvais dire “il y a du PHP sur ce serveur” à partir des en-têtes HTTP, autant j’ai plus de mal à affirmer “il y a du langage X ou Y sur ce serveur”. Ce parce que je sais que, généralement, si une version de PHP est exposée, ce sera via les en-têtes X-Powered-By ou Server ; alors que pour d’autres langages, j’en suis moins sûr.


Pour résumer : mon seul but quand je collecte ces données et calcule les quelques stats qui vont en face, c’est de déterminer quelles sont les versions de PHP utilisées, sur les domaines que j’identifie comme ayant une version de PHP installée. Et je publie ces quelques chiffres, en espérant qu’ils intéresseront ceux qui passent par là autant qu’ils m’intéressent moi (vu les retours que j’en ai eu, j’ai le sentiment que c’est le cas — et donc, je continue à publier).

J’espère que ces quelques lignes ont permis d’éclairer un peu les choses (je me permet de vous envoyer un mail pour attirer votre attention et dire “j’ai répondu”, vu que je n’ai pas de flux RSS sur les commentaires) ; merci encore pour votre commentaire.

8. Par Fnux le 2013-01-22 08:20
Fnux

Merci pour vos éclaircissements qui sont parfaitement valides.

Personnellement j’utilise PHP depuis 5 ans et j’ai déjà réalisé de très gros sites de type Web2 en conjonction avec Javascript et depuis peu avec CSS3.

Cependant, le but de ma question sur les 75 % des sites n’utilisant pas PHP est double :

1- quels sont les autres solutions (qui sont quand même majoritaires pour les 3 quarts des sites que vous avez interrogé) ?

2- d’essayer de comprendre pourquoi PHP n’est pas plus répandu (seulement 25 % des sites) ?

Les sous questions qui en découlent sont :

a- est-ce que PHP n’est pas adapté à tel ou tel besoin ?

b- est-ce que PHP n’est pas assez (ou trop mal) enseigné (Fac, IUT, AFPA, etc.)?

c- est-ce que PHP est trop lourd (ou trop lent) ?

d- est-ce pour ces différentes raisons que PHP perd régulièrement des places au classement TIOBE (alors qu’avec toutes les récentes évolutions depuis la 5.3 et surtout la 5.4 il devrait en gagner) ?

Etant un véritable adepte de ce langage script (j’utilise aussi le C, C++, Java, Go, Lua et même un peu de Scala), votre publication est très intéressante et c’est aussi la raison qui me permet de vous suggérer, lors de vos prochaines analyses, d’essayer si possible d’inclure au moins les ratios d’utilisation de PHP par type de serveur, et même éventuellement un sous classement par type d’OS utilisé.

Je pense que vous conviendrez que cela peut être très instructif pour différentes actions de promotion de PHP.

En tout cas, merci de votre réponse.

Cordialement. Fnux.

9. Par Rezouce le 2013-01-22 15:51
Rezouce

@Fnux, Parmi les sites non-PHP, il y en a une partie qui le sont malgré tout mais ne le révèlent pas. Voir par exemple : http://mark.koli.ch/2009/04/howto-set-expose-phpoff-in-phpini-to-hide-php-version-in-http-headers.html

10. Par Pascal MARTIN le 2013-01-22 21:37
Pascal MARTIN

@Fnux > pas de problème pour les éclaircissements ; au contraire, content qu’ils aient éclaircis :-) (et ça me fait une série d’explications auxquelles je pourrai faire référence les prochaines fois — même si je n’avais jusqu’à présent jamais pris la peine de mettre tout ça “sur papier”, il fallait bien que je m’attende à ce que quelqu’un, un jour, demande plus d’informations)

A présent, pour essayer de répondre aux questions que vous soulevez :

Tout d’abord, pour le point :

2- d’essayer de comprendre pourquoi PHP n’est pas plus répandu (seulement 25 % des sites) ?

Sur les réponses HTTP que j’ai obtenu avec succès, j’en ai identifié 25% comme indiquant “moi j’ai du PHP”.

Cela dit :

  • Peut-être que j’ai loupé une partie des informations : il est possible (même si je ne suis que peu convaincu, pour ce qui est de PHP) que les informations “j’ai tel langage” figurent dans d’autres en-têtes HTTP que les Server et X-Powered-By que j’ai analysé.
  • En fait, dans mon processus de collecte / analyse de données, je ne cherche absolument pas à répondre à la question “quelle techno il y a dans cette réponse HTTP ?”, mais, plutôt à “est-ce qu’il y a du PHP dans cette réponse HTTP ?”.
    Considérant la question que je me pose, il est plus facile de dire “oui il y a du PHP / non il n’y a pas de PHP” que de dire “le langage est X/Y/Z”.
  • Il y a une part (très certainement non-négligeable, même si je suis incapable de la mesurer puisque je ne sais pas identifier “tous” les langages) de serveurs qui n’exposent pas les logiciels utilisés.

Pour illustrer le troisième point, je vais illustrer par un exemple : si je prends www.france.fr, j’obtiens comme en-têtes de réponses HTTP :

Cache-Control: must-revalidate
Connection: keep-alive
Content-Length: 52800
Content-Type: text/html; charset=utf-8
Date: Tue, 22 Jan 2013 19:01:01 GMT
Etag: "bf3ae7910f6d4fbf814ce10508179835"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Tue, 22 Jan 2013 16:40:01 GMT
Server: -
X-WR-MODIFICATION: Content-Length

A partir de là, j’ai du mal à déterminer quoi que ce soit qui m’intéresse ; j’ai bien une en-tête Server (qui indique généralement le logiciel serveur utilisé, comme Apache ; et des fois sa version ; et des fois aussi les modules activés, comme PHP ; avec des fois leurs versions) ; mais vous admettrez que là, l’information est tout sauf “utile”… et je n’ai pas de X-Powered-By.

Pourtant, si je regarde le code HTML de la page, je vois quelques portions qui attirent mon attention (j’en reproduis brutalement quelques lignes “hors contexte”) :

<script type="text/javascript" src="/misc/drupal.js?V"></script>
jQuery.extend(Drupal.settings, { "basePath": "\/", "

Ces deux lignes (les inclusions de CSS en "/sites/all/modules/..." et de JS en "/sites/all/themes/" sont également une bonne piste) indiquent quasiment à coup sûr que le site est développé avec le CMS Drupal comme base ; et Drupal est un CMS développé en PHP (j’avoue, j’ai un peu triché : je me souviens du scandale au moment où le site a été lancé et s’est rapidement écroulé sous la charge ; à ce moment là, je bossais sur des sites de presse avec un peu de traffic, ils étaient en drupal, ils marchaient, et quand il y avait un problème, il ne nous fallait pas des semaines pour le corriger ^^ ).

Donc je peux affirmer de manière quasi-certaine que www.france.fr est développé en PHP ; que le serveur correspondant a PHP d’installé, donc.
Et pourtant, ce serveur ne fait pas parti de ceux que je compte comme “faisant tourner du PHP” : l’analyse que je viens de faire, je l’ai faite “à la main”, et elle ne fait pas parti de mes scripts.

Ce où je veux en arriver (et @Rezouce a déjà pointé ceci dans son commentaire) est que les logiciels et leurs versions ne sont pas nécessairement / toujours exposés.

Au contraire, on recommande parfois de masquer ces informations (Cf directive expose_php), en particulier pour éviter d’afficher à la terre entière “hou hou mon serveur il a une vieille version de PHP, trouée de failles de sécurité, et il est tout sauf à jour”.

Donc : les chiffres qui comptent à mes yeux, c’est “sur les serveurs que j’ai identifié comme étant en PHP, combien sont en chaque version”.

Et plus ou moins par conséquent et de manière liée : j’ai identifié 25% de serveurs faisant tourner du PHP ; mais ça ne veut aucunement dire qu’il n’y a pas (beaucoup ?) plus de serveur qui font tourner du PHP, et que je n’aurais pas identifié.


Pour répondre en second à votre premier point :

1- quels sont les autres solutions (qui sont quand même majoritaires pour les 3 quarts des sites que vous avez interrogé) ?

Considérant que je n’ai pas cherché à extraire cette information (j’ai cherché à répondre à la question “est-ce qu’il y a du PHP ?”, et pas “qu’est-ce qu’il y a ?”), je ne peux donner aucun chiffre en ayant confiance dans sa fiabilité.

Pour réussir à avancer quelques chiffres, il me faudrait, au minimum :

  • Savoir, pour chaque langage, si il expose (dans une partie non-négligeable de cas, même si ça peut être désactivé comme c’est le cas avec PHP) l’information “je suis X, en version Y”,
  • Savoir, pour chaque langage, où est cette information,
  • Savoir extraire cette information — par exemple, j’ai des en-têtes X-Powered-By qui contiennent "Zope (www.zope.org), Python (www.python.org)" ; sans faire de moulinette spéciale, je dirais que le langage est "Zope" ; alors qu’il s’agit de Python…
  • Savoir extraire ces informations pour la majorité des langages, pour que les données “non-extraites / non-identifiées” ne représentent qu’un faible pourcentage ne venant pas polluer les vrais nombres,
  • Et que j’ai confiance dans les points décrits au-dessus — à la fois dans le fait que “je sache où est l’info”, et dans le fait que “mon script l’extraye correctement”.

Aujourd’hui, je n’ai pas la réponse à ces points pour “l’ensembles des langages” ; et donc, je ne suis pas en mesure de déterminer de manière fiable les solutions utilisées sur les “autres que 25% identifiés comme étant du PHP”.

(Ca ne répond pas à la question, désolé ; mais je ne peux pas faire mieux)


a- est-ce que PHP n’est pas adapté à tel ou tel besoin ?

J’ai bossé en PHP sur pas mal de types de “projets”, dont, un peu en vrac :

  • des bouts de commandes (suffisament courts pour que je les tape directement dans le shell, sans même créer de fichier),
  • des scripts ; d’un peu toutes les tailles ; faisant tout et n’importe quoi (du parsing de fichiers, des requêtes en base de données, des requêtes distantes, de l’analyse de gros volumes de données),
  • des petites applications “faites main” ; idem pour des petits sites “fait main”,
  • des sites de taille raisonnable “fait main”, avec et sans framework, certains bien foutus, d’autres moins bien,
  • des sites plus ou moins d’e-commerce (certains en développements spécifiques basés sur des frameworks ; d’autres basés sur des solutions existantes genre Magento) ; ça rentre dans la catégorie “applications transactionnelles”, pour certains composants,
  • des sites de presse (sous drupal, notamment ; certains avec de bonnes architectures avec pas mal de serveurs et tout),
  • des applications métier lourdes / complexes / riches brassant de bons gros volumes de données,
  • …

Dans tous les cas, PHP a répondu a mon besoin principal (l’appli web ou le script) ; d’aucun diraient que ma vision est faussée, vu que PHP et tout ce qui va autour est la stack technique que je connais le mieux (je ne fais pas non plus “que” du PHP ; et il est fréquent d’utiliser des composants développés avec d’autres technos, que ça soit du C, du SQL, du JAVA, du shell, du Perl, du Javascript, … c’est quelque chose qui est complètement naturel à mes yeux, aujourd’hui.).

En soit, en généralisant horriblement, je dirais que PHP est une “bonne solution” ; mais ce qui compte, souvent, ce n’est pas le langage ; mais bien ce qu’on en fait ;-)


b- est-ce que PHP n’est pas assez (ou trop mal) enseigné (Fac, IUT, AFPA, etc.)?

Ca fait quelques années que j’ai quitté l’école (j’ai eu mon DUT en 2003 ; et mon master en 2006) ; mais je n’y ai fait que peu de PHP (un peu de “fait main” à titre d’initiation au développement web ; et un peu de smarty quelques années après histoire de refaire un peu de dev web un brin structuré).

J’aurais tendance à dire que, oui, PHP n’est pas assez enseigné à l’école.

Mais est-ce que le rôle de l’école est d’enseigner un langage particulier ?

J’ai fait pas mal de C/C++ quand j’étais en DUT (c’est ce que j’ai le plus fait, j’aimais ça ; mon projet d’année en seconde année était en C++ — d’autres ont fait leur projet d’année en PHP) ; j’ai fait beaucoup de Perl (j’aimais ça, aussi) quand j’étais en licence/master (alors que d’autres faisaient du JAVA — on était souvent assez libre du langage qu’on choisissait pour implémenter nos solutions ; le langage n’étant rien de plus qu’un outil)… et je n’ai quasiment pas fait de C/C++ ni de Perl en 7 ans d’entreprise — alors que ça fait 6 ans et demi que je fais du PHP dans ma vie professionnelle (alors qu’à la sortie de l’école, si j’étais resté sur “ce que je connais”, ce n’est pas du PHP que j’aurais fait).

Cela dit, je ne suis pas le seul à penser qu’un peu plus de PHP en école (ou autre langage de script comme Ruby/Python, par rapport, par exemple, à du JAVA ou du C++ bien lourd) ne ferait pas de mal : ça fait parti des points sur lesquelles l’AFUP essaye de travailler.


c- est-ce que PHP est trop lourd (ou trop lent) ?

PHP n’est peut-être pas “le meilleur outil” pour tout ; mais de là à dire “trop lourd / trop lent”…

D’expérience, quand on a une appli “lente” en PHP, il y a bien des choses à améliorer avant de vraiment pouvoir considérer que PHP est “lent / lourd” ; en vrac :

  • Déjà, se rappeller que le “but premier” de PHP, c’est la mise en place d’applications web ; ça peut vouloir dire qu’il peut parfois être judicieux d’utiliser une autre techno / un autre outil pour certains composants de l’ensemble applicatif dont le site web peut n’être qu’un petit bout.
  • Optimisation des requêtes SQL ; j’ai déjà vu des requêtes horribles, des tables plus que mal indexées, des mauvaises approches genre requêtes dans des tripples boucles imbriquées qui auraient pu être ré-écrites en une seule requête avec la jointure qui va bien, …
  • Optimisation des algos ; juste réfléchir un peu avant de coder, ou faire une passe de pair programming / revue d’architecture / revue de code, ça peut faire des miracles,
  • Configurer correctement son serveur ; ce n’est pas nécessairement facile, c’est vraiment un autre métier que “développeur web / php” (même si certains refusent parfois de le voir), mais ça peut aider beaucoup (rien que le truc tout bête d’installer et activer APC, ça peut faire vraiment du bien à la charge CPU d’un serveur — je l’ai vu plusieurs fois. Configurer correctement APC, ça fait une second phase de gain CPU souvent non-négligeable — là aussi, je l’ai vu plusieurs fois.)

Rien qu’avec ça… il y a de quoi faire vraiment du bien.

Après, il faut aussi penser à la facilité d’écrire du code ; et encore plus aux coûts de maintenance : OK, écrire une appli en C ça peut donner quelque chose de plus rapide (à condition que les algos soient bons, que les requêtes soient bonnes, qu’il n’y ait pas de truc “stupide” — comme en PHP en fait) ; mais d’un autre côté, s’il faut 5 fois (chiffre pris complètement au hasard) plus longtemps pour coder le truc, et qu’il faut 10 fois plus de temps de maintenance… heu… le calcul est vite fait : ça coutera moins cher d’acheter/louer un second serveur (d’autant plus que trouver un développeur Web qui connaisse PHP est certainement moins difficile que de trouver un développeur Web qui connaisse C).

Dans ma vie professionnelle, deux fois, je (et collègues / clients autour de moi) me suis demandé “est-ce que ce truc là ça vaudrait le coup d’en faire une extension PHP — codée en C, donc” :

  • La première fois (il y a plus de 5 ans de ça), on a optimisé quelques requêtes SQL et suprimé quelques appels web services ; ça a pris quelques jours ; ça fait des années que le code PHP est en production, personne ne s’est jamais reposé la question “extension écrite en C ?”.
  • La seconde fois, pour une portion de code PHP qui fait plein de calculs, je n’ai aucun doute que la ré-écrire en C sous forme d’une extension PHP permettrait de gagner un peu de temps ; mais même si jamais je le fais un jour (ça serait uniquement pour le fun ^^), jamais cette extension ne sera livrée en production : beaucoup trop compliqué à maintenir !

Enfin, pour résumer : si dans votre entreprise il y a des développeurs PHP qui connaissent leur job, il vaut très certainement mieux rester sur PHP et son écosystème (au moins pour le gros de l’appli web — pour certains composants qui gravitent autour, par contre… ), quitte à faire une passe d’optimisation de temps en temps, que de partir sur un truc qui, peut-être, fera gagner un peu de CPU… mais coutera au final une blinde en maintenance.

Ah, aussi : j’ai souvenir d’un site de presse ; avant de mettre en production, on a fait des tirs de performances ; la plate-forme ne tenait pas la charge visée… On a fait une passe d’optimisation pour corriger quelques énormités, et on a mis un reverse-proxy-cache — Varnish — devant les serveurs Apache, avec des durées de cache entre 1 et 5 minutes selon les pages (des délais courts, qui nous semblaient constituer un bon compromis pour un site de presse)… Bah bizarrement, ça a tout de suite mieux tenu la charge :-)

d- est-ce pour ces différentes raisons que PHP perd régulièrement des places au classement TIOBE (alors qu’avec toutes les récentes évolutions depuis la 5.3 et surtout la 5.4 il devrait en gagner) ?

Voyons voir, je regarde le classement TIOBE de ce mois-ci, j’ai :

  • C en première place ; pas surprenant, c’est le langage à la base d’une bonne partie des softs qu’on utilise tous les jours (le noyaux linux, un paquet d’outils Linux, PHP, postgresql, … et C a une bonne place dans l’embarqué.)
  • Suivi de Java (qui a toujours une bonne place dans les “grosses applis métier”, et qui a aussi sûrement bénéficié des développeurs Android),
  • Puis Objective-C (principale le développement d’apps sur iphone et assimilables, j’imagine),
  • C++ (Avec C, C++ doit correspondre au gros des applications “desktop”),
  • C# (un peu pareil je suppose),
  • Et PHP en 6ème place.

Avec ça :

  • PHP arrive comme “premier” langage orienté Web (Java et C# permettent de faire du Web, mais je doute que ça représente le plus gros des développeurs JAVA/C#),
  • PHP arrive “premier” devant tous les autres langages de script ; y compris ceux “assez orientés web” comme Ruby/Python ou même Javascript,
  • PHP est à la même 6ème place qu’en janvier 2012.

Je ne suis pas tellement le classement TIOBE, mais en tant que “langage orienté web”, PHP ne me parait pas si mal placé ?
(j’irais jusqu’à me demander comment il pourrait être “mieux” classé, en fait ?)

PHP était peut-être en troisième place tout début 2010… mais s’il est “descendu” dans le “classement”, est-ce que c’est parce qu’il est moins apprécié ? Ou parce que d’autres langages (genre C# et Objective-C, qui ne sont pas tellement orientés web) ont “progressé” ?


votre publication est très intéressante

Merci :-)

vous suggérer, lors de vos prochaines analyses, d’essayer si possible d’inclure au moins les ratios d’utilisation de PHP par type de serveur

Je prends note de la suggestion ; je ne pense pas la mettre en application tout de suite (un de ces jours, il va falloir que je revoie l’architecture utilisée pour collecter les données ; ça va probablement déjà me prendre plus que le temps que je peux raisonnablement passer sur ces stats), mais je la garde à l’esprit.

même éventuellement un sous classement par type d’OS utilisé

Noté aussi ; mais celle-là, ça me semble fort peu probable.

(Encore une fois, ce qui m’intéresse, ce sont les versions de PHP — pas ce qu’il y a en-dessous : PHP 5.3.21 sur du Apache, ou du nginx, ou du Windows+IIS, ça reste du PHP 5.3.21 — et c’est cette information là que je cherche)


Et là… j’ai encore pondu un roman ; ça fait deux soirs de suite… je me demande si un jour, je ne réutiliserai pas une partie de tout ça dans un article ^^

Merci encore pour vos commentaire :-)

Ajouter un commentaire

Saisissez votre commentaire, en utilisant la syntaxe Markdown.