Performance minable en général à cause du php (chargement de l'appli énorme à chaque requête). Zend limite un peu le problème mais plante aléatoirement sur ma machine
En réalité quand on maîtrise un peu l'environnement PHP, et que l'application n'est pas trop débile, on peut pallier ce problème facilement.
Je m'explique: les gros framework tels que Zend 2 et Symfony 2 (attention le 2 est important dans les deux cas) vont user de magie pour faire du lazy loading sur tous les composants applicatifs avec ce qu'ils appellent le "dependency injection container". Si l'appli est bien construite, le bootstrap (phase d'init du framework) est désolante de rapidité, et la construction de ta page est relativement rapide grâce au lazy loading.
Ceci est un cas d'utilisation (gros framework) qui est très sujet à controverse; La règle du lazy loading s'applique cependant sur tout type d'application, et est assez facile à mettre en œuvre sans les gros mots exprimés dans le paragraphe précédent.
De plus, quand on maîtrise la configuration et le tuning de PHP lui même, qu'on le met en démon (FPM ou tout aussi bien le bon vieux démon CGI) en tunant bien l'utilisation CPU/nombre de process/utilisation mémoire, et qu'on lui balance un OPCode cache au trognon, on atteint des performances bien plus que raisonnables qui peuvent faire pâlir d'envie assez facilement n'importe quel serveur d'application Java/Python/Ruby sur lequel on aurait fait tourner une application lambda pas particulièrement reconnue pour sa fougue.
J'ai beaucoup de mal avec KDE moi aussi, principalement parce que je n'aime pas les applications fournies avec. J'ai utilisé longtemps KMail du temps de KDE 3.x mais aujourd'hui j'utilise Evolution (ayant abandonné KMail à cause d'un grand nombre de bugs) et je le préfère de loin. Quitte à utiliser Evolution, je n'ai pas d'intérêt à utiliser KDE car avec GNOME et sa suite applicative, tout s'intègre.
Et puis je trouve Plasma assez inutile pour l'utilisation que j'en fais.
J'utilise GNOME Shell 3.6 sur mon desktop, et pour cette utilisation "familiale" je le trouve très bien.
Je continue à utiliser GNOME 3.6 en mode "Fallback" sur ma machine de boulot: je retrouve tout ce dont j'ai besoin comparé à GNOME 2.x, avec une ergonomie similaire à ce dernier.
Je comprends qu'il puisse en énerver plus d'un ceci dit, car l'ergonomie change radicalement et il manque encore un peu de possibilités de configuration/customisation par défaut.
Mais perso, je le trouve très crédible, seule chose manquante à ce jour pour mon utilisation c'est la synchro avec Owncloud (qui viendra dans la version 3.8).
Oui ça déborde parfois un peu chez PHP, mais globalement ça corrige plus de choses que ça n'en rouvre à travers le temps, ce qui fait que en moyenne en ça.
Content que t'ai vu ma petite pique sur Python, c'était juste gratuit^ J'en fais moi même de temps en temps.
Posté par pri .
En réponse à la dépêche ownCloud 4 est sorti.
Évalué à 5.
Dernière modification le 24 mai 2012 à 17:42.
Le protocole HTTP n'a pas de bugs en soit, probablement des failles je ne suis pas assez expert sur le sujet pour en discuter, cependant pour ce qui est de PHP, un certain nombre de récents patch on mis place des protections contre d'éventuelles DDoS liés à des envois excessifs de données pouvant amener à des écrasements de données.
De mémoire, ce n'est pas le seul langage/application à mettre en place ces protections dans le même laps de temps. Faudrait que je retrouve des liens là dessus.
Plusieurs choses:
- Déjà, le lien fourni qui pointe vers un bug Ubuntu repose sur une version PHP patchée Suhosin, ce qui déjà en soit potentiellement induit des comportements différents de PHP vanilla;
- De plus, il est lié à une fonctionnalité obsolète (magic_quote_gpc) que plus personne n'utilise. Dans les applications récentes les seules références qu'on puisse en voir sont souvent pour corriger des problèmes liés à un environnement où cette option obsolète serait par mégarde activée. Les applications PHP qui nécessitent cette option ont surement de beaucoup plus gros problèmes puisqu'apparemment elles n'ont pas évolué depuis 10 ans (contrairement au langage et à la VM);
- En ce qui concerne les régressions qu'il indique, on peut quand même voir que l'espacement entre la release qui créé cette régression et celle qui la corrige est un peu plus de deux semaines, c'est certes beaucoup, mais aucune distribution considérée comme stable n'aura normalement mis à jour à ce rythme là.
On pourrait en discuter pendant longtemps, et oui PHP à beaucoup de bugs, mais c'est pas le seul. J'ai bien l'impression que les gens ici s'acharnent sur un langage qu’apparemment ils ne connaissent pas ou peu. Sa couche objet était certes très pauvre jusqu'à peu, ils ont fait des choix étonnants en terme de syntaxe, mais je veux dire, d'autres l'ont fait aussi, certains langages sont encore whitespace based (WTF seriously).
Attention, ne vous méprenez pas, j'ai beau le défendre, je donnerais beaucoup pour retourner faire du Java ou du C# de temps en temps; je ne suis ni un fanatique, ni un molusque mono-langage, cependant j'aimerais quand même que les gens soient un peu plus objectifs quand ils émettent ce genre de critiques.
Pour travailler avec la stack L**P presque quotidiennement depuis quelques années, je sais ce très bien ce qu'il en est des bugs PHP, j'en rencontre moi même de temps en temps, mais dans l'absolu, à l'utilisation quotidienne, une bonne connaissance du langage et de ses capacités produisent du code qui n'est quasiment jamais impacté.
Et puis, très honnêtement, avant de pouvoir exploiter une faille d'exécution de code arbitraire, faut déjà avoir la main sur la machine ou tomber sur une application qui ne filtre aucune entrée utilisateur, c'est pas trivial.
Posté par pri .
En réponse à la dépêche ownCloud 4 est sorti.
Évalué à 2.
Dernière modification le 24 mai 2012 à 14:50.
Bien sûr, mais ça reste un détail important.
Entre parenthèses, concernant l'utilisation mono-utilisateur, ça ne veut pas dire que ton application ne va pas essuyer des traitements parallèles, surtout dans le web d'aujourd'hui où les applications vont aller s'amuser à faire des requêtes HTTP asynchrones dans tous les sens (AJAX) etc…
De plus, dans le cadre d'une application comme OwnCloud, on va très vite, même si mono-utilisateur, y brancher plusieurs logiciels (client mail, client pour son calendrier, montages WebDAV pour les fichiers, lecture de musique en ligne, etc…), ce qui tend à faire exploser le nombre de requêtes parallèles que va traiter ton application.
Même tout seul, ma remarque à un peu de sens, encore une fois ça dépend de l'application.
Les WebSockets ne sont pas triviales à mettre en place, le support au niveau des HTTPd est souvent expérimental, ou existe uniquement sous la forme de plugins contribués non officiels.
Il ne faut pas oublier que les WebSockets sont un gros hack du protocole HTTP, qui a probablement inventé parce que les gens ont oublié ce qu'est un socket à la base. C'est bien c'est beau c'est vendeur et ça passe les proxy, supaire, mais en dehors de ça, c'est une surcouche bien immonde au protocole HTTP (qui n'a jamais été conçu pour ça), et en dessous c'est pas encore super bien pris en charge par l'écosystème applicatif actuel.
Déjà il ne faut pas comparer l'incomparable: les applications Java tournent souvent dans un serveur d'application au sein duquel la mémoire est partagée pour toutes les requêtes entrantes.
PHP fonctionne en mode CGI, quant bien même il consomme peu de mémoire (et ce n'est pas toujours vrai, ça dépend de l'application au dessus) toutes les requêtes entrantes vont consommer sensiblement la même quantité de mémoire. Ceci y compris quand on l'utilise en mode démon (FPM et ancêtres).
La conséquence de ceci c'est que PHP consommera linéairement autant de mémoire que de requêtes concurrente arrivent, ce qui normalement ne se produit pas quand on utilise un serveur d'application portant des applications bien conçues capable de partager correctement les ressources.
Encore une fois, ça reste incomparable et cette remarque est non pertinente car la consommation mémoire dépend de l'application, pas du langage, et très peu de la VM (car oui, PHP aussi fonctionne dans une VM).
PHP ne fait pas que corriger des failles de sécurité qui lui appartiennent, mais pose aussi des brides liées au protocole HTTP, que les serveurs web eux-même ne corrigent pas toujours.
Dire que le langage est mauvais parce qu'ils corrigent beaucoup de failles et un peu facile, il faut aussi se placer dans le contexte.
Pour information, la dernière fois que j'ai lancé les tests unitaires de PHP, seuls 7 (sur plusieurs milliers) ne sont passés, et ce sont des comportements connus liés à l'architecture 64bits, qui, à ma connaissance, n'ont pas d'impact sur le code utilisateur.
[^] # Re: Wordpress puxore
Posté par pri . En réponse au journal Code facétieux dans Piwik 1.9.2. Évalué à 2. Dernière modification le 29 novembre 2012 à 11:48.
Je suis globalement d'accord avec tout sauf:
En réalité quand on maîtrise un peu l'environnement PHP, et que l'application n'est pas trop débile, on peut pallier ce problème facilement.
Je m'explique: les gros framework tels que Zend 2 et Symfony 2 (attention le 2 est important dans les deux cas) vont user de magie pour faire du lazy loading sur tous les composants applicatifs avec ce qu'ils appellent le "dependency injection container". Si l'appli est bien construite, le bootstrap (phase d'init du framework) est désolante de rapidité, et la construction de ta page est relativement rapide grâce au lazy loading.
Ceci est un cas d'utilisation (gros framework) qui est très sujet à controverse; La règle du lazy loading s'applique cependant sur tout type d'application, et est assez facile à mettre en œuvre sans les gros mots exprimés dans le paragraphe précédent.
De plus, quand on maîtrise la configuration et le tuning de PHP lui même, qu'on le met en démon (FPM ou tout aussi bien le bon vieux démon CGI) en tunant bien l'utilisation CPU/nombre de process/utilisation mémoire, et qu'on lui balance un OPCode cache au trognon, on atteint des performances bien plus que raisonnables qui peuvent faire pâlir d'envie assez facilement n'importe quel serveur d'application Java/Python/Ruby sur lequel on aurait fait tourner une application lambda pas particulièrement reconnue pour sa fougue.
[^] # Re: Passer à KDE ?
Posté par pri . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 0.
J'ai beaucoup de mal avec KDE moi aussi, principalement parce que je n'aime pas les applications fournies avec. J'ai utilisé longtemps KMail du temps de KDE 3.x mais aujourd'hui j'utilise Evolution (ayant abandonné KMail à cause d'un grand nombre de bugs) et je le préfère de loin. Quitte à utiliser Evolution, je n'ai pas d'intérêt à utiliser KDE car avec GNOME et sa suite applicative, tout s'intègre.
Et puis je trouve Plasma assez inutile pour l'utilisation que j'en fais.
[^] # Re: Passer à KDE ?
Posté par pri . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 2.
J'utilise GNOME Shell 3.6 sur mon desktop, et pour cette utilisation "familiale" je le trouve très bien.
Je continue à utiliser GNOME 3.6 en mode "Fallback" sur ma machine de boulot: je retrouve tout ce dont j'ai besoin comparé à GNOME 2.x, avec une ergonomie similaire à ce dernier.
Je comprends qu'il puisse en énerver plus d'un ceci dit, car l'ergonomie change radicalement et il manque encore un peu de possibilités de configuration/customisation par défaut.
Mais perso, je le trouve très crédible, seule chose manquante à ce jour pour mon utilisation c'est la synchro avec Owncloud (qui viendra dans la version 3.8).
[^] # Re: Jaildesk
Posté par pri . En réponse au sondage Que mettez vous sur votre bureau ?. Évalué à -2.
GNOME 3 en mode "Fallback" a encore un bureau (et oui, tant que Nautilus reste Nautilus, ça marche encore!).
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 1.
Oui ça déborde parfois un peu chez PHP, mais globalement ça corrige plus de choses que ça n'en rouvre à travers le temps, ce qui fait que en moyenne en ça.
Content que t'ai vu ma petite pique sur Python, c'était juste gratuit^ J'en fais moi même de temps en temps.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 5. Dernière modification le 24 mai 2012 à 17:42.
Le protocole HTTP n'a pas de bugs en soit, probablement des failles je ne suis pas assez expert sur le sujet pour en discuter, cependant pour ce qui est de PHP, un certain nombre de récents patch on mis place des protections contre d'éventuelles DDoS liés à des envois excessifs de données pouvant amener à des écrasements de données.
De mémoire, ce n'est pas le seul langage/application à mettre en place ces protections dans le même laps de temps. Faudrait que je retrouve des liens là dessus.
Plusieurs choses:
- Déjà, le lien fourni qui pointe vers un bug Ubuntu repose sur une version PHP patchée Suhosin, ce qui déjà en soit potentiellement induit des comportements différents de PHP vanilla;
- De plus, il est lié à une fonctionnalité obsolète (magic_quote_gpc) que plus personne n'utilise. Dans les applications récentes les seules références qu'on puisse en voir sont souvent pour corriger des problèmes liés à un environnement où cette option obsolète serait par mégarde activée. Les applications PHP qui nécessitent cette option ont surement de beaucoup plus gros problèmes puisqu'apparemment elles n'ont pas évolué depuis 10 ans (contrairement au langage et à la VM);
- En ce qui concerne les régressions qu'il indique, on peut quand même voir que l'espacement entre la release qui créé cette régression et celle qui la corrige est un peu plus de deux semaines, c'est certes beaucoup, mais aucune distribution considérée comme stable n'aura normalement mis à jour à ce rythme là.
On pourrait en discuter pendant longtemps, et oui PHP à beaucoup de bugs, mais c'est pas le seul. J'ai bien l'impression que les gens ici s'acharnent sur un langage qu’apparemment ils ne connaissent pas ou peu. Sa couche objet était certes très pauvre jusqu'à peu, ils ont fait des choix étonnants en terme de syntaxe, mais je veux dire, d'autres l'ont fait aussi, certains langages sont encore whitespace based (WTF seriously).
Attention, ne vous méprenez pas, j'ai beau le défendre, je donnerais beaucoup pour retourner faire du Java ou du C# de temps en temps; je ne suis ni un fanatique, ni un molusque mono-langage, cependant j'aimerais quand même que les gens soient un peu plus objectifs quand ils émettent ce genre de critiques.
Pour travailler avec la stack L**P presque quotidiennement depuis quelques années, je sais ce très bien ce qu'il en est des bugs PHP, j'en rencontre moi même de temps en temps, mais dans l'absolu, à l'utilisation quotidienne, une bonne connaissance du langage et de ses capacités produisent du code qui n'est quasiment jamais impacté.
Et puis, très honnêtement, avant de pouvoir exploiter une faille d'exécution de code arbitraire, faut déjà avoir la main sur la machine ou tomber sur une application qui ne filtre aucune entrée utilisateur, c'est pas trivial.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 2. Dernière modification le 24 mai 2012 à 14:50.
Bien sûr, mais ça reste un détail important.
Entre parenthèses, concernant l'utilisation mono-utilisateur, ça ne veut pas dire que ton application ne va pas essuyer des traitements parallèles, surtout dans le web d'aujourd'hui où les applications vont aller s'amuser à faire des requêtes HTTP asynchrones dans tous les sens (AJAX) etc…
De plus, dans le cadre d'une application comme OwnCloud, on va très vite, même si mono-utilisateur, y brancher plusieurs logiciels (client mail, client pour son calendrier, montages WebDAV pour les fichiers, lecture de musique en ligne, etc…), ce qui tend à faire exploser le nombre de requêtes parallèles que va traiter ton application.
Même tout seul, ma remarque à un peu de sens, encore une fois ça dépend de l'application.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 0.
Les WebSockets ne sont pas triviales à mettre en place, le support au niveau des HTTPd est souvent expérimental, ou existe uniquement sous la forme de plugins contribués non officiels.
Il ne faut pas oublier que les WebSockets sont un gros hack du protocole HTTP, qui a probablement inventé parce que les gens ont oublié ce qu'est un socket à la base. C'est bien c'est beau c'est vendeur et ça passe les proxy, supaire, mais en dehors de ça, c'est une surcouche bien immonde au protocole HTTP (qui n'a jamais été conçu pour ça), et en dessous c'est pas encore super bien pris en charge par l'écosystème applicatif actuel.
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 2.
Déjà il ne faut pas comparer l'incomparable: les applications Java tournent souvent dans un serveur d'application au sein duquel la mémoire est partagée pour toutes les requêtes entrantes.
PHP fonctionne en mode CGI, quant bien même il consomme peu de mémoire (et ce n'est pas toujours vrai, ça dépend de l'application au dessus) toutes les requêtes entrantes vont consommer sensiblement la même quantité de mémoire. Ceci y compris quand on l'utilise en mode démon (FPM et ancêtres).
La conséquence de ceci c'est que PHP consommera linéairement autant de mémoire que de requêtes concurrente arrivent, ce qui normalement ne se produit pas quand on utilise un serveur d'application portant des applications bien conçues capable de partager correctement les ressources.
Encore une fois, ça reste incomparable et cette remarque est non pertinente car la consommation mémoire dépend de l'application, pas du langage, et très peu de la VM (car oui, PHP aussi fonctionne dans une VM).
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par pri . En réponse à la dépêche ownCloud 4 est sorti. Évalué à 0.
PHP ne fait pas que corriger des failles de sécurité qui lui appartiennent, mais pose aussi des brides liées au protocole HTTP, que les serveurs web eux-même ne corrigent pas toujours.
Dire que le langage est mauvais parce qu'ils corrigent beaucoup de failles et un peu facile, il faut aussi se placer dans le contexte.
Pour information, la dernière fois que j'ai lancé les tests unitaires de PHP, seuls 7 (sur plusieurs milliers) ne sont passés, et ce sont des comportements connus liés à l'architecture 64bits, qui, à ma connaissance, n'ont pas d'impact sur le code utilisateur.