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.
|