MySQL : pool de connexions

2 réponses

Auteur	Message
Bool \| Modérateur Inscrit le : 09/05/2005	# Le 03/12/2007 à 22:23 Hello, je recontre un petit soucis sur de plus en plus de machines : le code PHP est assez rapide, les requetes SQL aussi, mais c'est la connexion SQL le "goulet d'étranglement".... malgré l'utilisation du "thread cache" de MySQL et la désactivation des reverse DNS. Je m'interesse donc aux solutions de "pool de connexions" et aimerait savoir si certains d'entre vous en utilise déjà ou non. Pour le moment j'en ai deux en vue : - SQLRelay : projet de longue date, stable, mais implique une modification du code PHP actuel - MySQL Proxy : projet tout nouveau, en phase de développement, aucune modification de code necessaire Avez vous des retours d'utilisation de l'un ou l'autre ? Ou bien d'une solution différente ? daevel : infogérance et conseil \|\| moi
MathieuC \| Mathieu Modérateur Inscrit le : 15/07/2005	# Le 03/12/2007 à 22:32 Soit c'est un boulet, soit c'est un goulot Perso j'ai pas ce probleme, pourtant TOUTES les pages utilisnet intensivement le serveur SQL (connexion / deconnexion a chaque page). As tu un thread_cache_size suffisant ? # thread_cache_size Combien de threads nous allons conserver en cache pour réutilisation. Lorsqu'un client se déconnecte, les threads du client sont mis en cache s'il n'y en a pas déjà thread_cache_size de conservé. Tous les nouveaux threads sont d'abord prélevé dans le cache, et uniquement lorsque le cache est vide, un nouveau thread est créé. Cette variable peut vous permettre d'améliorer les performances si vous avez de nombreuses connexions. Normalement, thread_cache_size ne donne pas d'amélioration notable si vous avez une bonne implémentation des threads. En examinant la différence entre les variables de statut Connections et Threads_created vous pouvez voir comment votre système de cache de threads est efficace. (see Section 5.2.4, « Variables de statut du serveur » pour plus de détails) Cette variable a été ajoutée en MySQL 3.23.16. Sinon effectivement, c'est peut etre du temps de perdu a cause des resolutions DNS, mais quand meme...
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 03/12/2007 à 22:40 Voui voui, le thread cache size est suffisamment grand et la résolution DNS est désactivée depuis le début sur ces machines. daevel : infogérance et conseil \|\| moi

Auteur

Message

Bool |
Modérateur

Inscrit le : 09/05/2005

# Le 03/12/2007 à 22:23

Hello,

je recontre un petit soucis sur de plus en plus de machines : le code PHP est assez rapide, les requetes SQL aussi, mais c'est la connexion SQL le "goulet d'étranglement".... malgré l'utilisation du "thread cache" de MySQL et la désactivation des reverse DNS.

Je m'interesse donc aux solutions de "pool de connexions" et aimerait savoir si certains d'entre vous en utilise déjà ou non.

Pour le moment j'en ai deux en vue :
- SQLRelay : projet de longue date, stable, mais implique une modification du code PHP actuel
- MySQL Proxy : projet tout nouveau, en phase de développement, aucune modification de code necessaire

Avez vous des retours d'utilisation de l'un ou l'autre ? Ou bien d'une solution différente ?

daevel : infogérance et conseil || moi

MathieuC | Mathieu
Modérateur

Inscrit le : 15/07/2005

# Le 03/12/2007 à 22:32

Soit c'est un boulet, soit c'est un goulot

Perso j'ai pas ce probleme, pourtant TOUTES les pages utilisnet intensivement le serveur SQL (connexion / deconnexion a chaque page). As tu un thread_cache_size suffisant ?

# thread_cache_size

Combien de threads nous allons conserver en cache pour réutilisation. Lorsqu'un client se déconnecte, les threads du client sont mis en cache s'il n'y en a pas déjà thread_cache_size de conservé. Tous les nouveaux threads sont d'abord prélevé dans le cache, et uniquement lorsque le cache est vide, un nouveau thread est créé. Cette variable peut vous permettre d'améliorer les performances si vous avez de nombreuses connexions. Normalement, thread_cache_size ne donne pas d'amélioration notable si vous avez une bonne implémentation des threads. En examinant la différence entre les variables de statut Connections et Threads_created vous pouvez voir comment votre système de cache de threads est efficace. (see Section 5.2.4, « Variables de statut du serveur » pour plus de détails) Cette variable a été ajoutée en MySQL 3.23.16.

Sinon effectivement, c'est peut etre du temps de perdu a cause des resolutions DNS, mais quand meme...

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 03/12/2007 à 22:40

Voui voui, le thread cache size est suffisamment grand et la résolution DNS est désactivée depuis le début sur ces machines.

daevel : infogérance et conseil || moi

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.