Le 27/08/2011 14:39, Pierre-Henry Muller a écrit :
L'application que le client fait développer ne comporte pas de mécanisme pour faire du split des requêtes, les développeurs ont dit que c'était compliqué et que ça couterait cher à développer, du coup c'est au niveau système qu'il faut trouver une solution.
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,