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,

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/