B'jour a tous
 
Etant developpeur PHP depuis un bon moment , j'ai trouvé du boulot en tant que dev, et j'ai donc été confronté a des méthodes de programmer totalement différentes de la mienne... La premiere chose qui m'a choqué c'est la suivante... Moi je suis autodidacte pur souche et le collaborateur qui a formulé cette remarque a un cursus de développeur bien baraqué    
 
Depuis que je programme et encore plus maintenant que je suis en POO complete PHP5 , j'ai pris l'habitude d'effectuer la connexion a MySQL lorsque j'instancie mon moteur de template dans mon constructeur de class.. et de fermer cette meme connexion dans le destructeur correspondant.
 
Néanmoins ce collaborateur m'a dis que point de vue sécurité il était mieux de ne créé la connexion a chaque requete et de la laisser fermée quand je ne m'en sert pas... A la limite soit, ce qui me chiffonne un peu c'est que la durée nécessaire a la connexion serveur n'est pas négligeable dans l'execution d'un script , aussi je me demande si c'est vraiment utile quand on sait qu'un script qui tourne sur une bonne machine met plus ou moins un dixieme de seconde a s'executer... ( Je dis bien en général , ca dépends du contenu ! )
 
Ma question est plus de type sondage en fait, histoire de savoir comment vous gérez de votre coté, ouverture au début et fermeture en fin de script , ou bien ouverture et fermeture a chaque requete ?

c'est peut-etre plus sécurisé (quoi que) mais c'est beaucoup plus lourd aussi.

l'argument de la securité, c'est du pipeautage, je vois mal comment qqn d'exterieur pourrait récuperer la ressource de la cnx ouverte.
Par contre c'est super lent parce que le plus lourd dans une requete, c'est le temps d'ouverture de la connexion, c'est de la très mauvaise programmation

ben tient, c'est marrant, autodidacte moi-aussi, c'est ouverture en début de script, fermeture en fin de script...
aurait-on du aller à l'école plus longtemps ???

bon ca me rassure !! Merci !

personnellement moi lors de l'affichage d'une page
j'ouvre ma connexion au debut de la page
je ferme ma connexion à la fin de la page
mais en aucun cas je laisse ouvert une connexion de cette manière, à quel moment peut on savoir que l'utilisateur quitte le site ?
Il y a pas une boule de cristal intégrée dans le serveur quand même.

moi aussi, plus exactement, je l'ouvre dés que j'en es besoin et je ferme dés que la derniére requette à été envoyé.
Ceci dit, comme le premier truc que je fais, c'est noter dans une table de log que telle page à été demandé et que le dernier truc que je fais, c'est noter dans la même table le temps passé et l'abscence d'erreur, on peut dire que ca revient exactement au même.
 

lui non plus visiblement vu qu'il dit bien qu'il ferme la conection à la base de donnée à l'aide du destructeur du template.
 
the_bigboo > Je te déconseille de mélanger accés à la base de donnée avec gestionnaire d'affichage. Tu seras content si t'es pas obligé de toucher au gestionnaire d'affichage (le gestionnaire de template) si ton patron veut passer à postgressql ou à Oracle et tu seras bien content de ne pas toucher à l'objet correspondant à la gestion des données si ton patron veut qu'une page puisse être envoyé à la demande sous forme de fichier pdf ou de fichier html ou dans un autre format.

Le problème à mon sens n'est pas la sécurité en tant que faille de sécurité, mais plutôt la sécurité en tant que fiabilité du script: une DB n'accepte habituellement qu'un nombre restreint de connections permanentes, donc si on ouvre ces connections plus longtemps que nécessaire on risque fort de se ramasser la limite de connections de la DB si les scripts sont longs et/ou qu'on a beaucoup d'utilisateurs => la moitié des utilisateurs se prennent une jolie trace leur expliquant que la connection à la DB n'a pu être effectuée... (90% du temps, ce genre d'erreurs n'est pas géré par les scripts, donc non seulement l'utilisateur n'a pas accès au service mais il a accès à des informations potentiellement importantes sur la structure interne de l'appli ou des serveurs)

Salut,
 
ce qu'il faut faire niveau rapidité c'est :
 
1) Connexion à la base
2) Tu fais toutes tes requêtes
3) Tu fermes la connexion
 
4) Tu fais le traitement de chacune des requêtes
 
Bien sûr c'est le cas idéal. Mais ouvrir et fermer la connexion juste avant et après une requête c'est stupide, de même que de garder la connexion ouverte pendant toute la durée de génération du script.
 
Le problème viendra des erreurs si ton site est visité de "max_user_connections" qui surviennent lorsque le max_user_connections est trop bas ou alors que ton script est mal conçu. En général chez beaucoup d'hébergeurs normaux, cette valeur est à 5 au moins, voire plus. ça suffit largement pour avoir un nombre de visiteurs très important sans erreur avec des scripts bien conçus. Si ta page met une seconde à se charger et que ta connexion reste ouverte, t'auras plein d'erreurs si t'as 5 mecs qui vont charger ta page en même temps...
 
Niveau sécurité je vois pas ce que ça apporte de plus, l'internaute qui est à l'extérieur n'est pas censé avoir accès au serveur mysql pour chopper ce qui transite...

chépas , les développeurs que je connaissent semblent parano...
Ils comptent mettre l'application sur un windows 2003 Serveur avec un apache2 win32    
 
Ce qu'ils oublient c'est qu'avec Microsoft , le danger vient très souvent de l'intérieur

Faut penser positif ... Ils auraient pu te coller un IIS + module php ..

Dites vous savez qu'un serveur sous Windows ça peut être très stable et très puissant, et puis cela dépend du type d'application métier qui tourne derrière

Oui, mais un IIS avec module php , faut pas pousser non-plus

Va expliquer ca a mon patron Il est microsoft a fond ca a été un enfer pour lui faire compredre que IIS c'etait  de la merde et que c'etait ( et c'est toujours ) buggé !

surtout que faire du PHP sur IIS avec seulement un module php.dll c'est mort d'avance, il reste les autres DLL qui je ne sais pas si elles fonctionnent avec
Mon dieu quand même

Attend, j'appelle la hotline de Microsoft pour leur signaler ton patron Demain, quand ils viendront controler les licences, tu verras que ton patron changera d'idée

Et pourtant ca fonctionne à mon boulot, les dll qu'étaient déjà utilisé marchent toujours même aprés avoir rajouter php5 en mode ISAPI.
On a IIS avec ASP pour une raison historique (et le fait que personne n'a envie de passer 6 mois à repasser tout le site en php et à se faire "BIP" avec la banque pour obtenir une API en php) et du PHP en suplément pour certaines nouvelles pages depuis que l'ancien webmaster c'est barré.
Et PHP en version isapi arrive trés bien à utiliser les modules php standard. (les dll)
 
Par contre, niveau architecture web, je déconseille de garder un site à cheval entre php et asp, ne seraisse que par ce que côté partage des données de session entre les deux, c'est le méga gros bordel et même si c'est moi qu'est réglé ce probléme, j'ai quand même l'impression que ca tient plus de la bidouille (et d'une faiblesse du controle de la validité d'une session côté asp) qu'autre chôse.

PHP5 je trouve ca M-O-N-U-M-E-N-T-A-L !!!
quelle évolution depuis PHP4 ! Ca a révolutionnéer mes objets ca !
Et pis ASP = microsoft , ca veut dire serveur windows ( Stabilité ? ) Achat de licences ( Mamamia ! ) et limité en nombre de connexion par le budget , alors que Apache + PHP5 = aussi performant que l'ASP mais aussi plus intuitif, portable et surtout gratuit / Opensource !

Ouais grave
 
C'est comme une sorte d'Arc de Triomphe en caca, alors qu'avant on avait juste une piscine de caca avec PHP4

Je crois qu'il faut arrêter avec les débat m$ €€. Il y a des boites a qui cela n'est pas un argument. Win2003 me semble t'il tres stable et niveau sécurité cela dépend autant de l'administrateur. Php fonctionne très bien sur du IIS bien patché.
Pour en revenir au début, mon chef de projet a la meme philosophie des connexion a chaque requete. Sécurité ? ppffff laisse moi rire . par contre coté ressource c'est plus ou moin discutable.
Ouvrir->Fermer->Ouvrir->Fermer il y a des situations ou cela ne peut pas trop passer, exemple : fonction recurcive ou chaque noeud = 1 connexion ouverte et/ou 1 profondeur = 1 connexion ouverte
Mais il y a quelqu'un qui a mis une raison positive et qui est fort juste c'est que lorsque tu es limité en nombre de connexion c'est une astuce pour déjouer les erreurs potentiels.  
J'organise mes scripts de telle sorte que la premiere chose que je fais c'est :
1- Récupérer les informations de la base
2- Ferme la connexion
3- Traite l'informations.
Je fais d'appelle à la db dans ma zone d'affichage html ou autre tous est préablement récupéré avant.
 
 
Au final. Cette technique provient des utilisateurs SQL Serveur qui parfois était limité en nombre de connexion à cause des licences mais ne connaissait pas l'existance de PoolConnexion.
Neanmoins, il est assez important de gérer le nombre de connexion potentiel sur son site.
J'avais fais un script qui ouvrait x connexions en même temps et faisait de la redistribution selon les disponibilités Exe:
Cas 1 il cherche une connexion ouverte une est libre
ConnA : true
ConnB : true
ConnC : false :non utilisée peut être utilisé
 
Cas 2 aucune connexion est disponible il tournera z fois jusqu'a qu'une sera relaché
ConnA : false :utilisée ne peut être utilisé
ConnB : false :utilisée ne peut être utilisé
ConnC : false :utilisée ne peut être utilisé
 
Avec 5 connexions j'avais géré une centaine d'utilisateur à la minutes. Le temps d'execution de la page ralongeais mais se faisait passé pour une légère lenteur du réseau en gros ni vu ni connu vas y que je t'embrouille

le truc c'est que si on ouvre la connexion au debut et qu'on la fermer qu'a la fin d'exécution du script , a supposer que par défaut ta base de donnée accepte X connexions simultannée , le jour ou tu vas en avoir X+10 , ton serveur sera completement occupé et devra attendre qu'un client ferme la connexion pour en ouvrir une autre...
 
mais une lenteur réseau quand meme, le création de la connexion représente un temps non négligeable, mais dans le cadre du projet que je développe , ca va etre 1500 voire 2000 utilisateurs simultanés... Donc je me tate...
 
Je fais pareil que toi au niveau gestion des donnée , je m'arange pour récupérer toute information avant renvoi de contenu HTML

c'est clair je suis daccord avec toi il y avait ce probleme.