Bonjour,

Quand j’exécute un script php qui se connecte à mysql, si la limite de connexions simultanés est atteinte, que faire ?

Est-ce mysql renvois un message que je pourrait exploiter coté php pour avertir mon visiteur ? Ou mieux, ce que je voudrais, est-ce possible d'attendre qu'une connexion se libère et d’exécuter la requête ensuite ?

Je cherche une solution qui est bien entendu possible d'utiliser sur un mutualisé.

Merci.

> Est-ce mysql renvois un message que je pourrait exploiter coté
> php pour avertir mon visiteur ?

Oui, mysql_connect (ou assimilés) renvoie une erreur "too many connections", paf.

> Ou mieux, ce que je voudrais, est-ce possible d'attendre qu'une
> connexion se libère et d’exécuter la requête ensuite ?

Cela monopoliserait un interpréteur PHP, donc ton serveur web crasherait.

> si la limite de connexions simultanés est atteinte, que faire ?

Plusieurs solutions.

Normalement, sur un gros site, on n'utilise jamais apache/mod_php directement.

- Soit on utilise un serveur qui tient la charge (comme lighttpd, nginx, zeus...) avec php/fastcgi derrière et un nombre limité de process php.

- Soit on utilise effectivement apache, mais avec un proxy/load balancer devant qui joue le même rôle, c'est-à-dire limiter le nombre de connections simultanées.

Dans les deux cas on a une sorte d' "entonnoir" qui prend un grand nombre de connections client et les envoie dans un petit nombre d'interpréteurs php et connections BDD, ce qui limite automatiquement le nombre de connections BDD, est plus performant, économise de la RAM, résoud les problèmes de locks, etc. Le serveur ou proxy gère la queue de requêtes HTTP.

Tu es sur un mutualisé, donc tu n'as pas le choix de la config (c'est généralement un load balancer avec apache derrière).

Mais bon, quand un site php/mysql explose comme dans ton cas, généralement la cause est mysql, à chercher dans :

- utilisation stupide de la BDD (chat php/sql, tracker torrent php/sql, traductions, etc)
- non-optimisation de l'utilisation de la BDD (pages avec 150 requêtes, etc)
- non-optimisation de la conception de la BDD (MyISAM, pas d'index, schéma pourri, fulltext, etc)
- non-optimisation du requêtage (jointures énormes, mysql_num_rows au lieu de count, etc)

et, parfois :

- mutualisé simplement pas assez performant (ou trop gratuit) pour le trafic considéré

Merci.

Je suis sur un plan pro OVH.

Il s'agit d'un jeu web en temps réel, les besoins du jeu font qu'une requête (via ajax) est envoyé au serveur toutes les secondes et par joueurs, en étant 20 sur une même map le problème est survenu une seule fois, mais impossible de lancer le jeu officiellement dans ces conditions.

OVH propose 4 bases (3 rapides et 1 de stockage) autorisant 10 connexions simultanés chacune, j'avais prévus le coup, alors les maps, les instances de combat et le tchat ont chacun leur base rapide. Toutes les donnés qui ne sont pas appelés en ajax (tout le reste donc) est sur la base de stockage.

Malheureusement malgré cette bonne organisation, ça ne suffit pas.


J'ai encore une question, est-ce que le problème pourrait venir de PDO ?
Il est possible de supprimer une instance PDO, je le fait dès que je n'en ai plus besoin, mais est-ce que ça coupe la connexion de la même façon que mysql_close() ?
Car sinon, ça voudrais dire que mes connexion sont ouvertes jusqu'à la fin des scripts ce qui n'aiderait pas vraiment...

Citation : grillon

Il s'agit d'un jeu web en temps réel, les besoins du jeu font qu'une requête (via ajax) est envoyé au serveur toutes les secondes et par joueurs, en étant 20 sur une même map le problème est survenu une seule fois, mais impossible de lancer le jeu officiellement dans ces conditions.

1 req/s/gus connecté, c'est énorme... tu aurais dû faire ce petit calcul avant !

> Malheureusement malgré cette bonne organisation, ça ne suffit pas.

lol, la seule bonne organisation pour ce type de chose est de ne pas le faire en php mais via un serveur spécial qui garde les connections ouvertes et ne refait pas une requête toutes les secondes.

> J'ai encore une question, est-ce que le problème pourrait venir de PDO ?

Non.

> Il est possible de supprimer une instance PDO, je le fait dès que je n'en ai plus besoin,
> mais est-ce que ça coupe la connexion de la même façon que mysql_close() ?

Je suppose, oui.

> Car sinon, ça voudrais dire que mes connexion sont ouvertes jusqu'à la fin des scripts ce qui n'aiderait pas vraiment...

Ton site ne peut pas tourner sur un mutualisé. Sur un dédié, si tu mets une config logicielle "performante" (lighttpd ou nginx + php/fastcgi) et que ton code est optimisé à mort, tu auras 2 ms de traitement par page, donc avec 4 cores, 2000 pages/s maximum, soit 2000 types connectés. Tu auras 2-3 process php et connections mysql par core, maximum.

Note que ce type de trafic, pour un site normal, doit correspondre à la page d'accueil d'un site comme cdiscount à l'heure de pointe des soldes de noël. Donc avec ton mutualisé... c'est même pas la peine.

Citation : Lord Casque Noir

lol

Bien entendu, mais tout le monde ne possède pas un porte monnaie sans fond. Je te remercie pour tes renseignements très utile, mais je me passerai volontier de ton mépris.

Je n'ai vu aucun mépris dans les réponses de Lord Casque Noir, au pire c'est une pointe vers PHP, pas vers toi.

Citation : grillon

Bien entendu, mais tout le monde ne possède pas un porte monnaie sans fond. Je te remercie pour tes renseignements très utile, mais je me passerai volontier de ton mépris.

Un kimsufi coûte à peine le prix de 3 paquets de clopes par mois... et si tu investis quelques mois de ton temps pour développer un site, c'est te mépriser toi-même de ne pas "investir" dans un petit dédié...

> au pire c'est une pointe vers PHP, pas vers toi.

Un peu, quand même... tu as je pense l'ambition d'avoir plein de membres sur ton site (ce qui est bon), mais tu n'as pas fait tes devoirs et lu le document indispensable à la survie :

http://fr.wikipedia.org/wiki/C10k_problem

qui t'explique pourquoi un petit site comme meetic utilise un "obscur" serveur web russe et non Apache, par exemple :

Citation

$ wget -O /dev/null -S http://www.meetic.fr
--2011-12-12 09:47:18-- http://www.meetic.fr/
Resolving www.meetic.fr... 62.23.30.24
Connecting to www.meetic.fr|62.23.30.24|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx

.. et accessoirement pourquoi personne (sauf sur les tuto du SdZ apparemment) n'implémente un chat php/mysql sur un site à succès...

Je dis ce que je pense : extrêmement bien optimisé, sur un dédié pas trop cher (genre bi-xeon), ton architecture supportera autour de 1000-2000 utilisateurs connectés (10x moins si tu ne connais pas la différence entre myisam et innodb). Donc, prévois dans ton planning de la refaire si le site a du succès.

En attendant, prends un kimsufi, mets nginx + php/fastcgi, et optimise.