Premièrement des applis web complexes qui scalent linéairement ça n'existe tout simplement pas. Donc pour "un nombre arbitrairement grand" c'est du grand n'importe quoi. Chaque archi à ses limites et tu choisis l'archi en fonction du cahier des charges. Après tu itères en fonction de l'évolution du trafic, de l'usage, des nouvelles fonctionnalités, des bottlenecks etc.
Deuxièmement écrire quelque chose qui supporte 1, 10, 1000 ou 100 000 000 de transactions/ seconde ca n'a pas le même coût. Tu ne peux viser au plus haut rien que pour la beauté du geste, ca coute très cher. Plus tu tapes haut, plus tu t'éloignes du "modèle traditionnel" et plus tu dois faire du custom. Quand tu as atteint les limites d'écriture de ton master DB, il est temps de passer à autre chose: caching type memcached, passer du relationnel à du key/value, déporter tout tes traitements en batch, découper tes bases en shard etc.
Ce genre de trucs, en plus d'être couteux, c'est pas forcement une bonne idée de le faire à priori. Ca donne un système complexe et "optimisé" en aveugle sans savoir ce qui va réellement poser problème en prod (et ca évolue très très vite).
[^] # Re: Comment ne rien améliorer
Posté par ckyl . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 10.
Premièrement des applis web complexes qui scalent linéairement ça n'existe tout simplement pas. Donc pour "un nombre arbitrairement grand" c'est du grand n'importe quoi. Chaque archi à ses limites et tu choisis l'archi en fonction du cahier des charges. Après tu itères en fonction de l'évolution du trafic, de l'usage, des nouvelles fonctionnalités, des bottlenecks etc.
Deuxièmement écrire quelque chose qui supporte 1, 10, 1000 ou 100 000 000 de transactions/ seconde ca n'a pas le même coût. Tu ne peux viser au plus haut rien que pour la beauté du geste, ca coute très cher. Plus tu tapes haut, plus tu t'éloignes du "modèle traditionnel" et plus tu dois faire du custom. Quand tu as atteint les limites d'écriture de ton master DB, il est temps de passer à autre chose: caching type memcached, passer du relationnel à du key/value, déporter tout tes traitements en batch, découper tes bases en shard etc.
Ce genre de trucs, en plus d'être couteux, c'est pas forcement une bonne idée de le faire à priori. Ca donne un système complexe et "optimisé" en aveugle sans savoir ce qui va réellement poser problème en prod (et ca évolue très très vite).
http://www.slideshare.net/techdude/scalable-web-architecture(...) résume bien les techniques courantes.
Bref pour une fois c'est bidon ce que tu dis. Attention j'ai pas dit qu'il fallait pondre une bouse dès le départ. non plus.