Nombre de session simultanées

Nombre de session simultanées - SQL/NoSQL - Programmation

Marsh Posté le 04-03-2016 à 23:31:45    

Bonjour  
 
Chez OVH la doc dit 30 connections simultanées maximales.  
 
Qu'est ce qui se cache derrière ceci ?  
 
Cela signifie-t-il que je ne peux pas exécuter plus de 30 requêtes en même temps (du coup c'est largement suffisant) ? ou que je ne peux pas avoir plus de 30 $_SESSION simultanées (du coup c'est largement insuffisant) ?  
 
Merci d'avance,

Reply

Marsh Posté le 04-03-2016 à 23:31:45   

Reply

Marsh Posté le 07-03-2016 à 14:01:58    

Je présume que vous faites référence à ce qui est écrit sur la page décrivant la base de données MySql des offres SQL-Perso et SQL-Pro : https://www.ovh.com/fr/hebergement-web/mysql.xml .
 
30 n'est pas le nombre de maximum $_SESSION simultanées, car $_SESSION est une variable du PHP qui concerne des sessions internet, et qui ne concerne pas MySql.
 
30 est le nombre maximum de ... connexions (comme indiqué). Cela implique que c'est aussi le nombre maximum de requêtes simultanées, puisque qu'à chaque connexion ne peut être associée qu'une requête à un instant donné. Mais si le programme ne déconnecte de la base de données 29 utilisateurs inactifs, alors un seul utilisateur actif pourra faire une requête. Il est donc recommandé d'écrire le programme de manière à ce qu'il fasse une connexion avant chaque requête, et une déconnexion après chaque requête, au lieu de faire une connexion avant un ensemble de requêtes et une déconnexion après cet ensemble, dans le cas, où cet ensemble de requêtes pourrait prendre beaucoup de temps. Ajouter une connexion et une déconnexion avant et après chaque requête augmente un petit peu le temps de traitement, mais il y a des systèmes de cache qui font que la deuxième connexion est généralement assez rapide. Une autre solution consiste à sérialiser les requêtes, c'est-à-dire à ne maintenir qu'une ou quelques connexions, et de faire passer les requêtes des différents utilisateurs dans une file d'attente, d'avoir une sorte d'entonnoir logiciel. Je l'ai fait dans le cas d'accès à une base de données Oracle qui était facturée au nombre de connexions, et ça marchait très bien.

Reply

Marsh Posté le 07-03-2016 à 14:17:41    

Pour avoir été chez OVH, c'est vraiment pAs le nb de requêtes simultanées qui pose pb. En effet, à moins d'avoir un grand nb d'utilisateurs connectés en même temps sur un site (ou outil web), coder ses scripts en faisant une connexion à la BD en début de script et en refermant la connexion en fin de script suffit (pas besoin d'ouvrir/fermer la connexion à la BD après chaque requête, sinon, les perfs vont êtres moisies).
 
Par contre, ce qui pose pb chez OVH (et c'est pour ça que j'en suis parti), et qui n'est pas écrit dans la doc, c'est qu'au bout d'un certain "critère technique" (je ne sais pas si c'est le nb de requêtes SQL faites dans un certain laps de temps, ou si c'est un temps de connexion d'un script à la BD, ou si c'est un autre critère technique), OVH coupe la connexion à la BD sans attendre que ton script ait terminé.
 
Du coup, si t'as codé ton script avec une connexion en début de script, ben le script continue de s'exécuter mais sans pouvoir continuer à manipuler la BD. Ca provoque pleins de bugs et comportements bizarres que tu n'as pas sur ta plate-forme de dév. Et t'as beau te dire que tu vas tester la connexion à la BD avant chaque requête et recréer la connexion s'il y a eu une déconnexion, ça ne marche pas : la connexion ne se fait pas. La connexion se fait à partir du moment où tu relances le script depuis le début :(
 
OVH met ça en place pour éviter des flood de requêtes SQL. Le pb, c'est que si ton appli web est un logiciel (de gestion par ex), si tu fais pas mal de requêtes (même des petites), tu te fais avoir. En fait, j'avais contourné partiellement le pb en faisant moins de petites requêtes et plus de grosses requêtes qui remontaient donc beaucoup plus de données, dans le but de limiter le nb de requêtes à la BD. Ca marchait pas trop mal mais c'était pas applicable à tous mes scripts :/
 
Chez 1&1, j'ai pas ce pb. :o


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 08-03-2016 à 18:01:51    

Bonjour,  
 
Merci pour vos réponses.
 
Effectivement, il semble implicite que ce soit 30 connexions max à la BDD et non au site (même si ce n'est pas 100% limpide)
 
rufo, merci de l'info, mais j'ai déjà un hébergement chez OVH, je reprend donc juste un nom de domaine pour le moment.  
 

Reply

Marsh Posté le 27-03-2016 à 11:21:59    

rufo a écrit :

Pour avoir été chez OVH, c'est vraiment pAs le nb de requêtes simultanées qui pose pb. En effet, à moins d'avoir un grand nb d'utilisateurs connectés en même temps sur un site (ou outil web), coder ses scripts en faisant une connexion à la BD en début de script et en refermant la connexion en fin de script suffit (pas besoin d'ouvrir/fermer la connexion à la BD après chaque requête, sinon, les perfs vont êtres moisies).
 
Par contre, ce qui pose pb chez OVH (et c'est pour ça que j'en suis parti), et qui n'est pas écrit dans la doc, c'est qu'au bout d'un certain "critère technique" (je ne sais pas si c'est le nb de requêtes SQL faites dans un certain laps de temps, ou si c'est un temps de connexion d'un script à la BD, ou si c'est un autre critère technique), OVH coupe la connexion à la BD sans attendre que ton script ait terminé.
 
Du coup, si t'as codé ton script avec une connexion en début de script, ben le script continue de s'exécuter mais sans pouvoir continuer à manipuler la BD. Ca provoque pleins de bugs et comportements bizarres que tu n'as pas sur ta plate-forme de dév. Et t'as beau te dire que tu vas tester la connexion à la BD avant chaque requête et recréer la connexion s'il y a eu une déconnexion, ça ne marche pas : la connexion ne se fait pas. La connexion se fait à partir du moment où tu relances le script depuis le début :(
 
OVH met ça en place pour éviter des flood de requêtes SQL. Le pb, c'est que si ton appli web est un logiciel (de gestion par ex), si tu fais pas mal de requêtes (même des petites), tu te fais avoir. En fait, j'avais contourné partiellement le pb en faisant moins de petites requêtes et plus de grosses requêtes qui remontaient donc beaucoup plus de données, dans le but de limiter le nb de requêtes à la BD. Ca marchait pas trop mal mais c'était pas applicable à tous mes scripts :/
 
Chez 1&1, j'ai pas ce pb. :o


 
Ca fait peur ton témoignage ! Surtout que toutes les appli web que je développe son chez ovh

Reply

Marsh Posté le 27-03-2016 à 14:28:05    

Tien, voilà le genre msg d'erreur que j'avais si je me souviens bien : MySQL server has gone away (Errno: 2006)
 
https://openclassrooms.com/forum/su [...] lise-48017
 
Après, sur des pages simples, c'était pas un soucis. Mais sur certaines pages complexes où j'avais de nombreuses requêtes, là, ça marchait pas correctement à chaque coup. Des fois, ça passait, des fois non :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed