Non, je n'ai pas spécialement de chiffre. Simplement des mauvaises expériences : sur un serveur dédié tout simple, faire tourner une appli Ruby on Rails avec une configuration par défaut ça fait vite planter le serveur dès que la fréquentation augmente.
Par exemple, j'ai voulu remplacé Trac (gestionnaire de projet en Python) par Redmine (gestionnaire de projet en Ruby) et plantages rapides du serveur. Déjà que Trac est très consommateur, c'était encore pire avec Redmine. Je suis resté sur Trac car je n'ai pas trouvé d'équivalent en PHP malheureusement. Mais j'ai dû faire des recherches et divers essais de tuning côté serveur pour réduire la consommation de ressources. Cette nécessité n'arrive que très rarement en PHP, le couple Apache + mod_php étant par défaut très performant (même si on peut faire beaucoup mieux avec du nginx par exemple).
L'une des grandes forces de PHP, c'est que l'environnement d'exécution est simple à mettre en place, par défaut très performant et peu consommateur.
Cela ne veut pas dire que Ruby c'est nul dans l'absolu. C'est sans doute intéressant pour des projets "spécifiques" qui n'ont pas vocation à être distribués (encore faut-il trouver des développeurs Ruby… et là encore PHP domine)
[^] # Re: PHP, ou comment condamner un bon projet à sa naissance
Posté par Pierrick Le Gall . En réponse à la dépêche ownCloud 4 est sorti. Évalué à -2.
Non, je n'ai pas spécialement de chiffre. Simplement des mauvaises expériences : sur un serveur dédié tout simple, faire tourner une appli Ruby on Rails avec une configuration par défaut ça fait vite planter le serveur dès que la fréquentation augmente.
Par exemple, j'ai voulu remplacé Trac (gestionnaire de projet en Python) par Redmine (gestionnaire de projet en Ruby) et plantages rapides du serveur. Déjà que Trac est très consommateur, c'était encore pire avec Redmine. Je suis resté sur Trac car je n'ai pas trouvé d'équivalent en PHP malheureusement. Mais j'ai dû faire des recherches et divers essais de tuning côté serveur pour réduire la consommation de ressources. Cette nécessité n'arrive que très rarement en PHP, le couple Apache + mod_php étant par défaut très performant (même si on peut faire beaucoup mieux avec du nginx par exemple).
L'une des grandes forces de PHP, c'est que l'environnement d'exécution est simple à mettre en place, par défaut très performant et peu consommateur.
Cela ne veut pas dire que Ruby c'est nul dans l'absolu. C'est sans doute intéressant pour des projets "spécifiques" qui n'ont pas vocation à être distribués (encore faut-il trouver des développeurs Ruby… et là encore PHP domine)