Bon alors en finalité, php est si rapide à compiler son code que les performances sont plutôt moins bonne (en tous cas ça ne change presque rien) si on va lire le bytecode en cache disque
Ca ne change rien : soit le cache de bytecode sert à quelque chose et Python fait aussi bien en standard que PHP+eaccelerator, soit il ne sert à rien et ce n'est pas la peine de prétendre qu'eaccelerator rend PHP plus rapide.
Dans les deux cas l'affirmation du wiki tuxfamily est totalement erronée.
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
ou alors distribuer les sites sur les noeuds
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.
[^] # Re: Incompatibilités ?
Posté par Antoine . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à -1.
Ca ne change rien : soit le cache de bytecode sert à quelque chose et Python fait aussi bien en standard que PHP+eaccelerator, soit il ne sert à rien et ce n'est pas la peine de prétendre qu'eaccelerator rend PHP plus rapide.
Dans les deux cas l'affirmation du wiki tuxfamily est totalement erronée.
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
ou alors distribuer les sites sur les noeuds
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.