Reprendre un article posté sur Slashdot pour lancer une discussion sur LinuxFr, c'est a priori une bonne idée.
Encore faut-il lire les commentaires sur Slashdot avant de reprendre aveuglément les chiffres cités, ça permet de comprendre rapidement que l'auteur de l'article s'est contenté de faire des extrapolations simplistes sans aucune connaissance réelle de l'architecture de Facebook.
Certains arguments ont déjà été cités ici.
Personnellement, j'insisterais sur:
- le facteur 10 provient de benchs de calcul pur, ils ne tiennent pas compte de:
1) la possibilité d'utiliser un accélérateur PHP. Il suffit de lire l'article http://blog.facebook.com/blog.php?post=2356432130 pour s'apercevoir que Facebook sait comment optimiser les performances de PHP.
2) les traitements PHP consistent souvent à interroger une base MySQL (qui est codé en C). L'impact de la performance de PHP sur la performance globale n'est probablement pas majeur.
- Facebook n'utilise pas que des serveurs PHP. Voir l'article http://www.datacenterknowledge.com/archives/2008/04/23/faceb(...) : 10000 serveurs sont utilisés uniquement pour gérer du cache.
De même, il faut quelques serveurs pour stocker les quelque 1,5 Po de photos (voir http://www.facebook.com/note.php?note_id=76191543919), avec 2,3 To de plus par jour. A raison de 10 To par serveur, je vous laisse faire la division. Et on n'a pas le nombre total de serveurs MySQL, répliqués sur deux datacenters.
Finalement, le gain potentiel en nombre de machines est probablement ridicule et largement contrebalancé par la simplicité de développement en PHP comparé à C++.
[^] # Re: Il y a tant de serveurs PHP chez facebook ?
Posté par netsurfeur . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 5.
Encore faut-il lire les commentaires sur Slashdot avant de reprendre aveuglément les chiffres cités, ça permet de comprendre rapidement que l'auteur de l'article s'est contenté de faire des extrapolations simplistes sans aucune connaissance réelle de l'architecture de Facebook.
Certains arguments ont déjà été cités ici.
Personnellement, j'insisterais sur:
- le facteur 10 provient de benchs de calcul pur, ils ne tiennent pas compte de:
1) la possibilité d'utiliser un accélérateur PHP. Il suffit de lire l'article http://blog.facebook.com/blog.php?post=2356432130 pour s'apercevoir que Facebook sait comment optimiser les performances de PHP.
2) les traitements PHP consistent souvent à interroger une base MySQL (qui est codé en C). L'impact de la performance de PHP sur la performance globale n'est probablement pas majeur.
- Facebook n'utilise pas que des serveurs PHP. Voir l'article http://www.datacenterknowledge.com/archives/2008/04/23/faceb(...) : 10000 serveurs sont utilisés uniquement pour gérer du cache.
De même, il faut quelques serveurs pour stocker les quelque 1,5 Po de photos (voir http://www.facebook.com/note.php?note_id=76191543919), avec 2,3 To de plus par jour. A raison de 10 To par serveur, je vous laisse faire la division. Et on n'a pas le nombre total de serveurs MySQL, répliqués sur deux datacenters.
Finalement, le gain potentiel en nombre de machines est probablement ridicule et largement contrebalancé par la simplicité de développement en PHP comparé à C++.