Actualités
Une astuce de performances est à la mode actuellement : cela consiste à remplir le cache de MySQL dès que possible, pour les requêtes qui en ont besoin puisse le solliciter. La situation où on peut prédire facilement les requêtes est la réplication : le log binaire apporte les requêtes de modifications, qui vont vider le cache de MySQL (les données sont rendues obsolètes).
Il suffit donc de lire les commandes UPDATE, attendre qu'elles soient traitées par l'esclave, puis les transformer en SELECT pour forcer MySQL à les mettre en cache pour les prochaines fois.
Sans passer par la réplication, il est peut être intéressant de compléter les UPDATE par des selects même sur un serveur simple. Idéalement, les SELECT de mise en cache doivent être exécutés par un thread séparés de celui qui fait des UPDATE : sinon, ce dernier est d'autant ralenti.
Il suffit donc de lire les commandes UPDATE, attendre qu'elles soient traitées par l'esclave, puis les transformer en SELECT pour forcer MySQL à les mettre en cache pour les prochaines fois.
Sans passer par la réplication, il est peut être intéressant de compléter les UPDATE par des selects même sur un serveur simple. Idéalement, les SELECT de mise en cache doivent être exécutés par un thread séparés de celui qui fait des UPDATE : sinon, ce dernier est d'autant ralenti.
Pre-fetch binlogs to speed up MySQL replication (172 visites)
| < Précédent | Suivant > |
|---|
Commentaires
Vous pouvez ajouter votre commentaire! |
Vous devez vous connecter pour commenter