Je ne sais plus comment je suis arrivé sur cette page, mais l’erreur 1040 – Too Many Connections est tellement classique pour ceux qui sont sur hébergement mutualisé, que j’ai eu envie d’y aller voir plus loin. Malheureusement ou heureusement pour moi, je n’ai que très rarement eu à me pencher sur cette erreur, notamment parce que j’aime beaucoup passer par le cache (sur ce blog, il est d’un peu plus de 24 heures, ce qui m’a bien sauvé lors que mon MySQL ne voulait plus démarrer à cause d’un problème de stockage disponible sur le serveur), et que la majorité du temps que vous viendrez ici, la page que vous verrez aura été générée depuis plusieurs heures.    

Du coup, quand la page sera demandée, seuls Nginx et Apache seront sollicités : PHP et MySQL resteront au repos.

JE ne suis pas du tout un DevConnect Member, mais j’aimais bien cette image 😀

J’ai trouvé sur le web deux pages intéressantes que je souhaite partager ici à propos de la configuration MySQL :

• Une page très intéressante donnant notamment deux configuration recommandées pour un MySQL, en fonction de la quantité de RAM disponible.
• Sur le site de MySQL, cette page rentre davantage dans les détails de l’utilisation du cache des tables en fonction de l’utilisation qui est faite.

L’intérêt de Memcache

De surcroît, il m’a semblé voir -je ne sais plus où- que les SGBD mettaient en cache les tables utilisées. Par exemple, si vous faites un SELECT de la table 1, le SGBD la mettra en cache, puis vous en retournera le résultat. Ainsi, une fois qu’elle est en cache, je doute qu’un SELECT soit trop long à sortir, car à mon avis l’opération la plus longue sera la mise en cache du contenu de la table.

Et du coup, je ne vois pas trop l’intérêt de MEMCACHE. J’ai regardé sur Wikipédia, et il me semble que l’exemple de code qu’ils proposent rejoint tout à fait l’utilisation que l’on peut faire de Memcache sur AppEngine. Or, sur AppEngine, Memcache n’est autre qu’une copie en RAM d’une partie de la BDD, ou plus couramment un résultat d’une interrogation de celle-ci. Ainsi, il me semble que MEMCACHE a pour effet de mettre en cache le résultat d’une commande (et pas seulement la table), ce qui donc évidemment se révèle encore plus rapide (car en cache), mais je serais intéressé par voir un comparatif de gain de performances entre une configuration sans MEMCACHE, et une configuration avec. Je pense que l’intérêt de MEMCACHE dépend évidemment des opérations faites sur les tables (dans la mesure où sauvegarder un résultat est d’autant plus intéressant lorsque l’opération prend du temps, avec des grosses tables et des jointures nombreuses), mais je ne sais pas si l’intérêt est grand lorsque les tables sont toutes déjà en RAM, et donc que les jointures et tri sur ces tables doivent aller assez vite. Encore une fois, cela dépend aussi de la taille des tables : quand elles font 5Go, et que l’index est inexistant/pas à jour, je me doute bien que les opérations vont être plus longues que pour des tables de simplement quelques Mo. Ce que je dis peut sembler idiot, mais je me souviens que sur AppEngine, le panel d’administration m’affichait de gros panneaux rouges lorsque j’utilisais directement la mémoire pour afficher le contenu de tables faiblement remplies, ce notamment pour m’inciter à utiliser Memcache à la place. Or, si la table est faiblement remplie, je reste dubitatif sur l’intérêt de la chose…