Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même,
De mon expérience, si et de plus en plus. Et les caches de opcode n'y peuvent rien d'ailleurs.
Tu dis php mais tu veux dire php bien écrit. Or php est une plate-forme particulièrement adapté au code de merde qu'il a le mérite de le faire tourner convenablement.
Je me permettrais donc de nuancer ton propos en remplaçant php par php correct et maîtrisé.
Ce que je vois de php, c'est que les principaux cms ont besoin de plus de mémoire (memory limit) et de plus de temps (max_execution_time) pour un resultat à peu près équivalent à ce qu'ils faisaient avant. Pour le memory_limit par exemple on est en passe d'arriver à un pseudo standard de 128 MO là ou il y a 3 ans on était entre 2 et 8. Tu peux passer ton serveur de 2 à 16 GO, le compte n'y est pas.
Je suis désolé mais je ne comprends pas pourquoi un site sous drupal presque vide ne tourne pas avec 32 MO de mémoire possible pour chaque script.
Je n'ai rien contre php en soit. Mais dire que "Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même" c'est un peu fort.
La tolérance de php au code pourris est sans doute avec, la méconnaissance de l'algèbre relationnelle et le spam, l'une des plus grande cause de surconsommation électrique actuelle.
Maintenant si tu parles de php utilisé convenablement, déployé en trois tiers avec par exemple nginx et spawn-fcgi, du code testé et tout le tintouin là c'est autre chose.
Toutefois il ne faut quand même pas oublier que php reste dans sa plus large acception le langage des jean-kevin qui ne comprennent pas comment utiliser plesk pour faire pointer "le CNAME de www.mondomaine.com/index.php vers le dns de 42.128.196.32".
Je te jure, il faut les avoir au tél toute la journée les "webmasters" qui te demande ce que tu entend par "maintenance du code" ou par "version de pre prod"
[^] # Re: Pas convaincu
Posté par Joris Dedieu (site web personnel) . En réponse au journal HipHop For PHP : Facebook php-to-C++ translator. Évalué à 7.
Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même,
De mon expérience, si et de plus en plus. Et les caches de opcode n'y peuvent rien d'ailleurs.
Tu dis php mais tu veux dire php bien écrit. Or php est une plate-forme particulièrement adapté au code de merde qu'il a le mérite de le faire tourner convenablement.
Je me permettrais donc de nuancer ton propos en remplaçant php par php correct et maîtrisé.
Ce que je vois de php, c'est que les principaux cms ont besoin de plus de mémoire (memory limit) et de plus de temps (max_execution_time) pour un resultat à peu près équivalent à ce qu'ils faisaient avant. Pour le memory_limit par exemple on est en passe d'arriver à un pseudo standard de 128 MO là ou il y a 3 ans on était entre 2 et 8. Tu peux passer ton serveur de 2 à 16 GO, le compte n'y est pas.
Je suis désolé mais je ne comprends pas pourquoi un site sous drupal presque vide ne tourne pas avec 32 MO de mémoire possible pour chaque script.
Je n'ai rien contre php en soit. Mais dire que "Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même" c'est un peu fort.
La tolérance de php au code pourris est sans doute avec, la méconnaissance de l'algèbre relationnelle et le spam, l'une des plus grande cause de surconsommation électrique actuelle.
Maintenant si tu parles de php utilisé convenablement, déployé en trois tiers avec par exemple nginx et spawn-fcgi, du code testé et tout le tintouin là c'est autre chose.
Toutefois il ne faut quand même pas oublier que php reste dans sa plus large acception le langage des jean-kevin qui ne comprennent pas comment utiliser plesk pour faire pointer "le CNAME de www.mondomaine.com/index.php vers le dns de 42.128.196.32".
Je te jure, il faut les avoir au tél toute la journée les "webmasters" qui te demande ce que tu entend par "maintenance du code" ou par "version de pre prod"
Brrrrrrrrrrr
J'en tremble encore