Salut, Entièrement d'accord avec toutes ces techniques, heureusement j'ai des clients qui comprennent les enjeux du côté applicatif et font souvent tout ce qu'il faut pour que l'architecture reste simple pour mieux marcher. Mais voilà quand on est fasse à des mamouths (nom que je donne aux grosses entreprises / administrations où il faut 5 réunions espacées de 1 à 2 semaines, autant de rapports plein de blabla et de schéma pour faire la moindre action) et qu'ils prennent la décision de ne pas toucher au code parce que l'entreprise qui fait le développement a dit que c'était compliqué, il faut bien trouver une solution sinon on dit que c'est toi qui n'est pas bon ... Bref éternel débat mais on est bien tous d'accord sur le fait que la bonne solution à l'heure actuelle est côté code sauf que Grégory va nous sortir un nouveau script lua qui va super bien faire son boulot.
Allé Greg un peu de pression au passage :P Le 30/08/11 00:35, Damien Claisse a écrit : > Hello, > > La solution côté système parait souvent plus simple et moins coûteuse > mais d'expérience elle finira toujours par te coûter bonbon à plus ou > moins long terme (tu vas monter du serveur de plus en plus gros, > empiler les rustines puis maintenir des rustines de rustines et perdre > du temps en maintenance), jusqu'au jour ou patatras, plus rien ne > tiendra la route, tu vas devoir tout refaire de zéro: l'application > doit aussi être scalable à son niveau. > > Bien entendu, les applis ne sont pas souvent pensées scalabilité > (cache, sharding ou au moins ventilation lecture/écriture SQL sur deux > connexions différentes), mais il est souvent possible de rajouter tout > ça de façon itérative, quitte à patcher au fur et à mesure l'appli: tu > fournis une seconde ip virtuelle portée par un keepalived/haproxy/etc > pour se connecter à des slaves répliqués, et tu demandes au(x) dev de > basculer les requêtes les plus consommatrices (et pas dépendantes de > l'éventuel lag de répli) dessus, puis ça tient un peu plus longtemps, > et tu réidentifies des requêtes à passer sur la répli, et ainsi de suite. > > Ca marche aussi avec la mise en place du cache applicatif (memcached > par exemple), et comme suggéré auparavant tu peux également monter un > reverse proxy cache (nginx, varnish ou autre) en amont sur des > requêtes qui n'ont pas besoin de trop de fraicheur, le but étant de ne > pas envoyer des requêtes inutiles sur ton serveur d'appli et ta DB. Tu > peux même commencer par le reverse proxy de façon totalitaire (genre > si pas de cookie qui dit que le type est logué alors page sortie du > cache) si l'appli est vraiment impossible à patcher et qu'il te faut > une amélioration de perfs pour hier. > > Bon courage, >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
