Message "trop de connexions" reçu par mes visiteurs.

[MClaveau]

Bonjour !

Ceci étant mon premier message ici, j'en profite pour saluer tout le monde.

Sur un site, on m'a signalé le message "Trop de connexions. Réessayez ultérieurement", qui empêche des internautes d'accéder aux pages, et dont je n'arrive pas à trouver la cause.


Je plante le décor :
- Site évènementiel, unique sur le serveur.
- Le site reçoit peu de visiteurs (2000 / mois ; maxi 50 par jour).
- Hébergé chez moi, avec accès via une liaison ADSL OrangePro (800 kBd effectif dans le sens montant/envoi).
- Il s'agit d'un volet technique d'un site hébergé ailleurs.
- Très peu d'images (4 en fait, de moins de 20 ko).
- HTML volontaire simple.
- CSS très petit.
- Très peu de javascript (uniquement pour rafraichir certains formulaires en AJAX).
- Requêtes HTTP toutes indépendantes.
- Pas de cookies ; les variables éventuelles sont codées en tant que paramètres des requêtes HTTP.
- Le site est construit en Python, avec Cherrypy comme serveur.
- Cherrypy est configuré pour accepter 100 "threads de connexions" simultanés.
- Le module SGBD est CHATA. La base est ouverte en permanence. CHATA ne gère pas la notion de connexion, et c'est ultrarapide (genre : extraction de 10 000 enregistrements dans une base de 100 000 en 0,04 s ; et les écritures sont gérées par une file multithreadée). Les volumes de données du site sont faibles : la plus grosse table a 35 000 enregistrements, les autres moins de 5000, et il n'y a que 6 tables.
- Test de perfs : 90 % des pages sont servies en moins de 0,1 s.
- Il y a un module de paiement par Paypal, mais il s'agit simplement d'un lien envoyé et oublié, le retour se faisant par une requête HTTP indépendante.


Le souci.

Par moment, certains visiteurs reçoivent le message "Trop de connexions. Veuillez réessayer ultérieurement."
Ce message, en français, apparait au moment où ils veulent accéder au site.
Pourtant, j'ai fait des tests, en me connectant plusieurs fois simultanément, de l'extérieur, via des adresses IP différentes (et avec plusieurs machines), sans problème.


Questions.

- Finalement, qu'est-ce qu'une "connexion" ? Mon site gère les requêtes HTTP, les unes après les autres.
Elles sont considérées comme isolées. La notion de connexion n'existe donc pas à son niveau.
Comme il n'y a qu'un seul socket entre le serveur et le routeur, je conçois mal cette notion
de "connexion".
- Quelles sont l'origine et la cause de ce message ? Avec les éléments suivants :
+ Cherrypy est en anglais, alors que le message est en français.
+ Se pourrait-il que ce soit Orange ? Mais j'ai des clients, qui avec le même genre de connexion ont plusieurs dizaines de PC connectés en permanence à Internet.
+ Mon site ne renvoie jamais ce message.
+ Dans les journaux (logs), j'ai vu jusqu'à plus de 10 personnes travaillant en même temps sur le site ; or, j'ai eu, au téléphone, un internaute qui voyait le message alors qu'il n'y avait que deux utilisateurs en cours...



Si quelqu'un avait une idée de l'origine du problème, je pourrais enfin chercher une solution.


Merci d'avance.

 

[jv2759]

- Finalement, qu'est-ce qu'une "connexion" ? Mon site gère les requêtes HTTP, les unes après les autres.
Elles sont considérées comme isolées. La notion de connexion n'existe donc pas à son niveau.
Comme il n'y a qu'un seul socket entre le serveur et le routeur, je conçois mal cette notion
de "connexion".

Normalement un serveur web ne doit pas gérer les connexion à la suite mais en même temps. La plupart du temps il ouvre plusieurs thread à l'écoute, et des qu'il ressoit un nouvelle connexion il ouvre un nouveaux thread pour toujours en avoir à l'écouter...

Car telle que tu le décrit toi, des qu'une personne fait une requette sur ton site, la connexion et occuper et donc ne peux en accepter d'autres, si pendant ce temps il y a une autres requette, cette second ne peux être servie et il ce peux que le message arrive à ce moment là...

Pourtant, j'ai fait des tests, en me connectant plusieurs fois simultanément, de l'extérieur, via des adresses IP différentes (et avec plusieurs machines), sans problème.

Il faudrait essayer des test de monter en charge un peux plus pousser, car si tu n'arrive pas à reproduire le problème toi, cela seras difficile de reproduire le problème

 

[MClaveau]

Re !

D'abord, merci de ta réponse.

Normalement un serveur web ne doit pas gérer les connexion à la suite mais en même temps. La plupart du temps il ouvre plusieurs thread à l'écoute, et des qu'il ressoit un nouvelle connexion il ouvre un nouveaux thread pour toujours en avoir à l'écouter...
Car telle que tu le décrit toi, des qu'une personne fait une requette sur ton site, la connexion et occuper et donc ne peux en accepter d'autres, si pendant ce temps il y a une autres requette, cette second ne peux être servie et il ce peux que le message arrive à ce moment là...

En fait, je me suis mal exprimé. Le serveur ouvre bien un thread par connexion (jusqu'à 100). Ce sont les appels à la base de données qui sont sérialisés.
Mais, je me pose toujours la question de la notion de connexion. Parce que, en pratique, si on sniffe la partie TCP/IP, on ne vois passer (arriver) que des requêtes HTTP encapsulées dans des trames TCP. Il n'y a qu'une seule connexion physique, c'est le câble réseau. Et, sur cette connexion physique, les trames TCP/IP, donc les requêtes HTTP, ne sont jamais simultanées. Elles se suivent. Donc, je suppose qu'il faut parler de connexions logiques. Mais alors, à partir du moment où les requêtes sont traitées avant que d'autres arrivent, où est située la notion de "maintien" d'une connxion ?

En plus, je ne suis pas sûr que ce soit lié au serveur Web. Car j'utilise le même serveur sur un site hébergé chez OVH (pour d'autres sites et usages), et là, il n'y a jamais eu ce genre de message.

J'en suis à me demander si ce ne serait pas le FAI (Orange), le pare-feu, ou même le routeur, qui accrocherait. Mais alors, pourquoi ça passerait par moment, et pas à d'autres ?

Enfin, je cherche aussi par ailleurs. Et, si je trouve un truc, je le signalerai ici.

Et puis, pour rester optimiste, le site a quand même relativement bien fonctionné, permettant d'enregistrer quelques milliers de formulaires. Le problème n'a concerné qu'environ 2 % des visiteurs, qui ont tous pu s'enregistrer utltérieurement.