> il faut plusieurs becanes avec la bdd, et plusieurs machines qui livrent, et plusieurs machines qui traitent.
De façon général/idéal, c'est bien.
Mais maintenant on peut avoir des quadri-coeur pour pas cher et avec des performances redoutables...
On trouve même des quadri quatri-coeur AMD avec une tenue en charge fabuleuse.
Avec PostgreSQL qui tient bien la charge, pour le mettre à genoux il faut un gros gros succès. Cerise sur le gâteau, tu peux mettre ta base de donnée (du moins les parties les plus utilisées et qui n'ont pas besoin d'être conservée de façon permanente comme les donnés de session) en mémoire vive (tmpfs). Dans ce cas il faut vraiment un truc de malade pour mettre à genoux le serveur.
NB : un bon paramétrage de PosgreSQL peut être aussi efficace que l'utilisation de tmpfs.
Pour ce qui bouffe le plus de cpu, c'est-à-dire la génération des pages html, tu peux mettre en oeuvre plusieurs bécanes très facile si la base de donnée est commune. Le goulot d'étranglement est évidemment la base de donnée, mais tu as de la marge.
Ce que je veux dire, c'est qu'avec la méthode "traditionnelle" (un server de base de données commun et plusieurs serveurs pour les pages html dynamiques) tu couvres au moins 99,99 % des besoins.
Pour aller "s'emmerder" avec Ror, MemCache et tout ça, il faut avoir des besoins très très très spéciques.
[^] # Re: Tenue en charge
Posté par IsNotGood . En réponse au journal Ror ne se porte plus très bien ? Quid des autres ?. Évalué à 0.
De façon général/idéal, c'est bien.
Mais maintenant on peut avoir des quadri-coeur pour pas cher et avec des performances redoutables...
On trouve même des quadri quatri-coeur AMD avec une tenue en charge fabuleuse.
Avec PostgreSQL qui tient bien la charge, pour le mettre à genoux il faut un gros gros succès. Cerise sur le gâteau, tu peux mettre ta base de donnée (du moins les parties les plus utilisées et qui n'ont pas besoin d'être conservée de façon permanente comme les donnés de session) en mémoire vive (tmpfs). Dans ce cas il faut vraiment un truc de malade pour mettre à genoux le serveur.
NB : un bon paramétrage de PosgreSQL peut être aussi efficace que l'utilisation de tmpfs.
Pour ce qui bouffe le plus de cpu, c'est-à-dire la génération des pages html, tu peux mettre en oeuvre plusieurs bécanes très facile si la base de donnée est commune. Le goulot d'étranglement est évidemment la base de donnée, mais tu as de la marge.
Ce que je veux dire, c'est qu'avec la méthode "traditionnelle" (un server de base de données commun et plusieurs serveurs pour les pages html dynamiques) tu couvres au moins 99,99 % des besoins.
Pour aller "s'emmerder" avec Ror, MemCache et tout ça, il faut avoir des besoins très très très spéciques.