Je suis actuellement sur un hebergement mutualisé chez PHPNet.
Lundi 24 août vers midi, problème au niveau de ma base de données :
"MySQL said:#12 - Can't read dir of './xxxxxxx/' (Errcode: 13)"
Alors là je me dis en début d'après midi que je vais les contacter.
Cela fait 1 journée et demi et toujours personne me réponds.
Téléphone : personne donc plusieurs messages
Téléphone astreinte 24/24 : personne donc plusieurs messages
Ouverture de trois ticket
J'ai poster un premier message sur le forum. Quelqu'un m'a répondu
qu'il avait le même problème que moi. Et dans l'après midi :
suppression du message.
J'ai poster alors un 2ème message pour savoir si d'autre personnes
avaient encore le problème: resuppression du message par
l'administrateur du forum.
Je veux bien croire que nos problèmes ne doivent pas figurer sur le
forum mais si c'est le seul moyen pour que l'equipe de PHPnet nous
entendent..
Bref, ils ont eu beau supprimer mes messages, il n'ont pas répondu à
mes différents tickets ouverts ni à mes messages télephonique pour
autant!
Même si c'est pour dire qu'il vont régler le problème mais pas de
suite, cela serait bien d'avoir des nouvelles. Là j'ai vraiment
l'impression que mon hébergeur fait le mort.
Je déconseille vivement PHPNet comme hébergeur à tout le monde.
PS : Thibaud si tu me lis : Comment faut-il faire pour vous contacter?
Réponds nous au moins, on va pas te manger!
Heu, depuis hier midi et sa roule ? Ben heureusement !!!! Moi, je suis chez phpnet depuis 18 mois, et sa roule aussi !
J Bruentaud
thailande-guide
Enfin pour l'instant le service est bien meilleur qu'avant (dans mon cas) pour a peine plus cher, que demander de plus ?
Tu ne fais pas preuve d'une grande objectivité mon cher.
Je compare :
400 Mo contre 500 Mo chez phpnet.org 15 Go contre 15 Go de BP 8 domaines hébergeables contre 20 50 compte email contre illimité 143,38 ? contre 100 ? chez phpnet.org, soit 43 % plus cher pour 100 Mo de mois et 12 domaines de moins....
Tu appelles cela "a peine plus cher" ?
Façon de voir les chose !!!!
PS : il n'y a que sur le nombre de bases Mysql où cette offre est plus intéressante. Mais avec seulement 8 domaines hebergeables, quel est intérêt de l'illimité ?
--
Jacky Brunetaud -------------------------------- http://www.thailande-guide.com : guide web de la Thaïlande. http://www.easy-thai.com : l'annuaire et moteur de recherche sur la Thaïlande. http://www.logiprat.com : services gratuits pour webmaster (livre d'or, annonces...) http://www.cartofolie.com : cartes postales virtuelles gratuites du monde. http://www.guyane-guide.com : portail de la Guyane Française.
Enfin pour l'instant le service est bien meilleur qu'avant (dans mon cas)
pour a peine plus cher, que demander de plus ?
Tu ne fais pas preuve d'une grande objectivité mon cher.
Je compare :
400 Mo contre 500 Mo chez phpnet.org
15 Go contre 15 Go de BP
8 domaines hébergeables contre 20
50 compte email contre illimité
143,38 ? contre 100 ? chez phpnet.org, soit 43 % plus cher pour 100 Mo de
mois et 12 domaines de moins....
Tu appelles cela "a peine plus cher" ?
Façon de voir les chose !!!!
PS : il n'y a que sur le nombre de bases Mysql où cette offre est plus
intéressante. Mais avec seulement 8 domaines hebergeables, quel est intérêt
de l'illimité ?
--
Jacky Brunetaud
--------------------------------
http://www.thailande-guide.com : guide web de la Thaïlande.
http://www.easy-thai.com : l'annuaire et moteur de recherche sur la
Thaïlande.
http://www.logiprat.com : services gratuits pour webmaster (livre d'or,
annonces...)
http://www.cartofolie.com : cartes postales virtuelles gratuites du monde.
http://www.guyane-guide.com : portail de la Guyane Française.
Enfin pour l'instant le service est bien meilleur qu'avant (dans mon cas) pour a peine plus cher, que demander de plus ?
Tu ne fais pas preuve d'une grande objectivité mon cher.
Je compare :
400 Mo contre 500 Mo chez phpnet.org 15 Go contre 15 Go de BP 8 domaines hébergeables contre 20 50 compte email contre illimité 143,38 ? contre 100 ? chez phpnet.org, soit 43 % plus cher pour 100 Mo de mois et 12 domaines de moins....
Tu appelles cela "a peine plus cher" ?
Façon de voir les chose !!!!
PS : il n'y a que sur le nombre de bases Mysql où cette offre est plus intéressante. Mais avec seulement 8 domaines hebergeables, quel est intérêt de l'illimité ?
--
Jacky Brunetaud -------------------------------- http://www.thailande-guide.com : guide web de la Thaïlande. http://www.easy-thai.com : l'annuaire et moteur de recherche sur la Thaïlande. http://www.logiprat.com : services gratuits pour webmaster (livre d'or, annonces...) http://www.cartofolie.com : cartes postales virtuelles gratuites du monde. http://www.guyane-guide.com : portail de la Guyane Française.
Anthony
"thailande-guide" a écrit
Et bien moi, ne vous en déplaise, je suis content. Après 2 ans passé chez un
soit disant pro, je doit dire que PHPNET me convient parfaitement après 18 mois. Le jour où se ne sera plus le cas, je le dirai.
Je suis chez celeo et content, et de même le jour ou je ne serai pas content, je le dirai aussi, y'a aucun doute là dessus.
Anthony
"thailande-guide" a écrit
Et bien moi, ne vous en déplaise, je suis content. Après 2 ans passé chez
un
soit disant pro, je doit dire que PHPNET me convient parfaitement après 18
mois. Le jour où se ne sera plus le cas, je le dirai.
Je suis chez celeo et content, et de même le jour ou je ne serai pas
content, je le dirai aussi, y'a aucun doute là dessus.
Moi, je suis chez phpnet depuis 18 mois, et sa roule aussi !
Perso j'ai que des problèmes chez eux, nos sites n'ont pas le même trafic...
Chez celeo c'est le top, le service technique répond moins d'une heure après avoir posté...
Anthony
Lionel
Stephane Kanschine wrote:
Je n'ai pas infirmé un quelconque ralentissement, juste savoir quelle genre de page peuvent nécessiter 5/8 requêtes.
ça te parait beaucoup ? J'ai certaines pages qui en font 4 ou 5 fois plus (lors du premier passage sur le site après déploiement, après une grande partie est mise en cache...)
Stephane Kanschine wrote:
Je n'ai pas infirmé un quelconque ralentissement, juste savoir quelle
genre de page peuvent nécessiter 5/8 requêtes.
ça te parait beaucoup ?
J'ai certaines pages qui en font 4 ou 5 fois plus (lors du premier passage
sur le site après déploiement, après une grande partie est mise en cache...)
Je n'ai pas infirmé un quelconque ralentissement, juste savoir quelle genre de page peuvent nécessiter 5/8 requêtes.
ça te parait beaucoup ? J'ai certaines pages qui en font 4 ou 5 fois plus (lors du premier passage sur le site après déploiement, après une grande partie est mise en cache...)
mandraxar
Stephane Kanschine wrote:
Je n'ai pas infirmé un quelconque ralentissement, juste savoir quelle genre de page peuvent nécessiter 5/8 requêtes.
ça te parait beaucoup ? J'ai certaines pages qui en font 4 ou 5 fois plus (lors du premier passage sur le site après déploiement, après une grande partie est mise en cache...)
Attention ce sont des requêtes de connection vers la base de données et
non pas des requêtes SQL.
Stephane Kanschine wrote:
Je n'ai pas infirmé un quelconque ralentissement, juste savoir quelle
genre de page peuvent nécessiter 5/8 requêtes.
ça te parait beaucoup ?
J'ai certaines pages qui en font 4 ou 5 fois plus (lors du premier passage
sur le site après déploiement, après une grande partie est mise en cache...)
Attention ce sont des requêtes de connection vers la base de données et
Je n'ai pas infirmé un quelconque ralentissement, juste savoir quelle genre de page peuvent nécessiter 5/8 requêtes.
ça te parait beaucoup ? J'ai certaines pages qui en font 4 ou 5 fois plus (lors du premier passage sur le site après déploiement, après une grande partie est mise en cache...)
Attention ce sont des requêtes de connection vers la base de données et
non pas des requêtes SQL.
Lionel
mandraxar wrote:
Attention ce sont des requêtes de connection vers la base de données et non pas des requêtes SQL.
oups. Alors je n'en ai qu'une seule par requete HTTP. Quel est l'interet d'en utiliser plus ?
mandraxar wrote:
Attention ce sont des requêtes de connection vers la base de données
et non pas des requêtes SQL.
oups. Alors je n'en ai qu'une seule par requete HTTP.
Quel est l'interet d'en utiliser plus ?
Attention ce sont des requêtes de connection vers la base de données et non pas des requêtes SQL.
oups. Alors je n'en ai qu'une seule par requete HTTP. Quel est l'interet d'en utiliser plus ?
Patrick Mevzek
mandraxar wrote:
Attention ce sont des requêtes de connection vers la base de données et non pas des requêtes SQL.
oups. Alors je n'en ai qu'une seule par requete HTTP. Quel est l'interet d'en utiliser plus ?
Les pages dynamiques et l'usage des SGBDR, tout un art... :-)
En général ca commence à la première itération par: dans toutes les pages, j'ouvre la connexion au SGBDR dès le départ, et je la ferme à la toute fin du script. Comme ca je suis sûr d'avoir ma connexion tout le long du programme. Au pire, on a une bonne grosse variable globale qu'on se traine pour pointer sur la connexion, au mieux on utilise une bibliothèque idoine, voire OO.
Au bout d'un moment on a des problèmes, si le script prend du temps, il monopolise une connexion au SGBDR, qu'il l'utilise réellement ou non, et souvent le nombre maximal de connexions simultanées est limité.
Donc, deuxième itération: on ouvre la connexion au SGBDR juste avant d'en avoir réellement besoin, et on la ferme juste après. Mais donc si on a deux requêtes SQL à faire avec ``autre chose'' entre les deux, on va ouvrir (et fermer) deux fois la connexion au SGBDR.
Ca résout le problème initial, mais cela en créé un autre: en général c'est moins performant, car ouvrir une connexion à un SGBDR ca prend du temps, surtout si on n'a pas de mécanisme de ``cache''/pool des connexions au SGBDR. Ca alourdit le code, puisqu'il faut systématiquement penser à ouvrir sa connexion, la fermer, etc...
Pour moi, la véritable solution, pour tout projet de taille importante, c'est d'avoir une couche supplémentaire, qui s'occupe de gérer les connexions au SGBDR. Bref, le fameux cache dont je parle au-dessus. Cette couche se connecte au SGBDR dès le lancement du serveur web et gère après les connexions, en ouvrant et en en fermant selon les besoins, et en tenant compte (ou en s'adaptant) aux limites comme le nombre de connexions simultanées autorisées. Le programme CGI se connecte donc en fait sur/via cette surcouche, et pour lui les opérations de connexion/déconnexion au SGBDR sont quasimment des NOP.
C'est bien sûr un peu plus complexe à mettre en oeuvre...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
mandraxar wrote:
Attention ce sont des requêtes de connection vers la base de données et
non pas des requêtes SQL.
oups. Alors je n'en ai qu'une seule par requete HTTP. Quel est l'interet
d'en utiliser plus ?
Les pages dynamiques et l'usage des SGBDR, tout un art... :-)
En général ca commence à la première itération par:
dans toutes les pages, j'ouvre la connexion au SGBDR dès le départ,
et je la ferme à la toute fin du script. Comme ca je suis sûr d'avoir ma
connexion tout le long du programme.
Au pire, on a une bonne grosse variable globale qu'on se traine pour
pointer sur la connexion, au mieux on utilise une bibliothèque idoine,
voire OO.
Au bout d'un moment on a des problèmes, si le script prend du temps, il
monopolise une connexion au SGBDR, qu'il l'utilise réellement ou non, et
souvent le nombre maximal de connexions simultanées est limité.
Donc, deuxième itération: on ouvre la connexion au SGBDR juste avant d'en
avoir réellement besoin, et on la ferme juste après. Mais donc si on a
deux requêtes SQL à faire avec ``autre chose'' entre les deux, on va
ouvrir (et fermer) deux fois la connexion au SGBDR.
Ca résout le problème initial, mais cela en créé un autre: en général
c'est moins performant, car ouvrir une connexion à un SGBDR ca prend du
temps, surtout si on n'a pas de mécanisme de ``cache''/pool des
connexions au SGBDR. Ca alourdit le code, puisqu'il faut systématiquement
penser à ouvrir sa connexion, la fermer, etc...
Pour moi, la véritable solution, pour tout projet de taille importante,
c'est d'avoir une couche supplémentaire, qui s'occupe de gérer les
connexions au SGBDR. Bref, le fameux cache dont je parle au-dessus.
Cette couche se connecte au SGBDR dès le lancement du serveur web et gère
après les connexions, en ouvrant et en en fermant selon les besoins, et
en tenant compte (ou en s'adaptant) aux limites comme le nombre de
connexions simultanées autorisées.
Le programme CGI se connecte donc en fait sur/via cette surcouche, et
pour lui les opérations de connexion/déconnexion au SGBDR sont quasimment
des NOP.
C'est bien sûr un peu plus complexe à mettre en oeuvre...
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Attention ce sont des requêtes de connection vers la base de données et non pas des requêtes SQL.
oups. Alors je n'en ai qu'une seule par requete HTTP. Quel est l'interet d'en utiliser plus ?
Les pages dynamiques et l'usage des SGBDR, tout un art... :-)
En général ca commence à la première itération par: dans toutes les pages, j'ouvre la connexion au SGBDR dès le départ, et je la ferme à la toute fin du script. Comme ca je suis sûr d'avoir ma connexion tout le long du programme. Au pire, on a une bonne grosse variable globale qu'on se traine pour pointer sur la connexion, au mieux on utilise une bibliothèque idoine, voire OO.
Au bout d'un moment on a des problèmes, si le script prend du temps, il monopolise une connexion au SGBDR, qu'il l'utilise réellement ou non, et souvent le nombre maximal de connexions simultanées est limité.
Donc, deuxième itération: on ouvre la connexion au SGBDR juste avant d'en avoir réellement besoin, et on la ferme juste après. Mais donc si on a deux requêtes SQL à faire avec ``autre chose'' entre les deux, on va ouvrir (et fermer) deux fois la connexion au SGBDR.
Ca résout le problème initial, mais cela en créé un autre: en général c'est moins performant, car ouvrir une connexion à un SGBDR ca prend du temps, surtout si on n'a pas de mécanisme de ``cache''/pool des connexions au SGBDR. Ca alourdit le code, puisqu'il faut systématiquement penser à ouvrir sa connexion, la fermer, etc...
Pour moi, la véritable solution, pour tout projet de taille importante, c'est d'avoir une couche supplémentaire, qui s'occupe de gérer les connexions au SGBDR. Bref, le fameux cache dont je parle au-dessus. Cette couche se connecte au SGBDR dès le lancement du serveur web et gère après les connexions, en ouvrant et en en fermant selon les besoins, et en tenant compte (ou en s'adaptant) aux limites comme le nombre de connexions simultanées autorisées. Le programme CGI se connecte donc en fait sur/via cette surcouche, et pour lui les opérations de connexion/déconnexion au SGBDR sont quasimment des NOP.
C'est bien sûr un peu plus complexe à mettre en oeuvre...
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Christophe Baegert
Patrick Mevzek wrote:
Pour moi, la véritable solution, pour tout projet de taille importante, c'est d'avoir une couche supplémentaire, qui s'occupe de gérer les connexions au SGBDR. Bref, le fameux cache dont je parle au-dessus. Cette couche se connecte au SGBDR dès le lancement du serveur web et gère après les connexions, en ouvrant et en en fermant selon les besoins, et en tenant compte (ou en s'adaptant) aux limites comme le nombre de connexions simultanées autorisées. Le programme CGI se connecte donc en fait sur/via cette surcouche, et pour lui les opérations de connexion/déconnexion au SGBDR sont quasimment des NOP.
C'est bien sûr un peu plus complexe à mettre en oeuvre...
Si déjà tu fais une couche permanente, autant pousser le principe jusqu'au bout, et faire ton script en FastCGI, il sera entièrement permanent, ce qui permet de rajouter des caches, de ne faire les tâches d'initialisation qu'au démarrage du script à pas à chaque hit et augmente donc considérablement la vitesse.
Par contre, sans FastCGI, et sans couche permanente, il suffit de concentrer au maximum toutes les requêtes à un endroit du script, d'ouvrir la connexion juste avant, et de la fermer juste après. Ca fait l'affaire dans 99% des cas, il faut vraiment avoir un script compliqué pour ne pas avoir la possibilité de faire toutes les requêtes en même temps (dans ce cas il faut en général repenser tout à partir de zéro, c'est qu'il y a un problème, un script web doit impérativement être léger).
Cordialement,
Christophe Baegert
Patrick Mevzek wrote:
Pour moi, la véritable solution, pour tout projet de taille importante,
c'est d'avoir une couche supplémentaire, qui s'occupe de gérer les
connexions au SGBDR. Bref, le fameux cache dont je parle au-dessus.
Cette couche se connecte au SGBDR dès le lancement du serveur web et gère
après les connexions, en ouvrant et en en fermant selon les besoins, et
en tenant compte (ou en s'adaptant) aux limites comme le nombre de
connexions simultanées autorisées.
Le programme CGI se connecte donc en fait sur/via cette surcouche, et
pour lui les opérations de connexion/déconnexion au SGBDR sont quasimment
des NOP.
C'est bien sûr un peu plus complexe à mettre en oeuvre...
Si déjà tu fais une couche permanente, autant pousser le principe jusqu'au
bout, et faire ton script en FastCGI, il sera entièrement permanent, ce qui
permet de rajouter des caches, de ne faire les tâches d'initialisation
qu'au démarrage du script à pas à chaque hit et augmente donc
considérablement la vitesse.
Par contre, sans FastCGI, et sans couche permanente, il suffit de concentrer
au maximum toutes les requêtes à un endroit du script, d'ouvrir la
connexion juste avant, et de la fermer juste après. Ca fait l'affaire dans
99% des cas, il faut vraiment avoir un script compliqué pour ne pas avoir
la possibilité de faire toutes les requêtes en même temps (dans ce cas il
faut en général repenser tout à partir de zéro, c'est qu'il y a un
problème, un script web doit impérativement être léger).
Pour moi, la véritable solution, pour tout projet de taille importante, c'est d'avoir une couche supplémentaire, qui s'occupe de gérer les connexions au SGBDR. Bref, le fameux cache dont je parle au-dessus. Cette couche se connecte au SGBDR dès le lancement du serveur web et gère après les connexions, en ouvrant et en en fermant selon les besoins, et en tenant compte (ou en s'adaptant) aux limites comme le nombre de connexions simultanées autorisées. Le programme CGI se connecte donc en fait sur/via cette surcouche, et pour lui les opérations de connexion/déconnexion au SGBDR sont quasimment des NOP.
C'est bien sûr un peu plus complexe à mettre en oeuvre...
Si déjà tu fais une couche permanente, autant pousser le principe jusqu'au bout, et faire ton script en FastCGI, il sera entièrement permanent, ce qui permet de rajouter des caches, de ne faire les tâches d'initialisation qu'au démarrage du script à pas à chaque hit et augmente donc considérablement la vitesse.
Par contre, sans FastCGI, et sans couche permanente, il suffit de concentrer au maximum toutes les requêtes à un endroit du script, d'ouvrir la connexion juste avant, et de la fermer juste après. Ca fait l'affaire dans 99% des cas, il faut vraiment avoir un script compliqué pour ne pas avoir la possibilité de faire toutes les requêtes en même temps (dans ce cas il faut en général repenser tout à partir de zéro, c'est qu'il y a un problème, un script web doit impérativement être léger).
Cordialement,
Christophe Baegert
Patrick Mevzek
Pour moi, la véritable solution, pour tout projet de taille importante, c'est d'avoir une couche supplémentaire,
[..]
Si déjà tu fais une couche permanente, autant pousser le principe jusqu'au bout, et faire ton script en FastCGI,
Oui, mais je préfère mod_perl, personnellement, ca va bien plus loin qu'une mise en cache :-) Mais ce n'est pas à mettre en toutes les mains, et ce n'est pas évident pour un hébergeur à faire en mutualisé.
il sera entièrement permanent, ce qui permet de rajouter des caches, de ne faire les tâches d'initialisation qu'au démarrage du script à pas à chaque hit et augmente donc considérablement la vitesse.
Nous sommes tout à fait d'accord.
Par contre, sans FastCGI, et sans couche permanente, il suffit de concentrer au maximum toutes les requêtes à un endroit du script, d'ouvrir la connexion juste avant, et de la fermer juste après. Ca fait l'affaire dans 99% des cas, il faut vraiment avoir un script compliqué pour ne pas avoir la possibilité de faire toutes les requêtes en même temps (dans ce cas il faut en général repenser tout à partir de zéro, c'est qu'il y a un problème, un script web doit impérativement être léger).
Là aussi tout à fait d'accord, ca rejoint ma deuxième itération décrite précédemment.
Il arrive souvent, quand les programmes commencent à être modularisé, qu'il y a plein de include dans tous les sens, et donc des requêtes SQL dans tous les sens (tout le monde ne pense pas à faire une couche d'abstraction d'accès aux données) et de tous les côtés, que cela devient pénible d'ouvrir/fermer partout (faut se trimballer login/mot de passe partout par exemple - oui je sais on peut faire un include).
Bref, c'est une solution qui marche bien, souvent, mais qui n'est pas sans conséquences (script plus ``long'' puisque travail supplémentaire de connexions multiples au cours du script).
Quant à tout repensez de zéro.... hum.... n'est-ce pas le cas de 90% des applications dans la nature :-) ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Pour moi, la véritable solution, pour tout projet de taille importante,
c'est d'avoir une couche supplémentaire,
[..]
Si déjà tu fais une couche permanente, autant pousser le principe
jusqu'au bout, et faire ton script en FastCGI,
Oui, mais je préfère mod_perl, personnellement, ca va bien plus loin
qu'une mise en cache :-)
Mais ce n'est pas à mettre en toutes les mains, et ce n'est pas évident
pour un hébergeur à faire en mutualisé.
il sera entièrement
permanent, ce qui permet de rajouter des caches, de ne faire les tâches
d'initialisation qu'au démarrage du script à pas à chaque hit et
augmente donc considérablement la vitesse.
Nous sommes tout à fait d'accord.
Par contre, sans FastCGI, et sans couche permanente, il suffit de
concentrer au maximum toutes les requêtes à un endroit du script,
d'ouvrir la connexion juste avant, et de la fermer juste après. Ca fait
l'affaire dans 99% des cas, il faut vraiment avoir un script compliqué
pour ne pas avoir la possibilité de faire toutes les requêtes en même
temps (dans ce cas il faut en général repenser tout à partir de zéro,
c'est qu'il y a un problème, un script web doit impérativement être
léger).
Là aussi tout à fait d'accord, ca rejoint ma deuxième itération décrite
précédemment.
Il arrive souvent, quand les programmes commencent à être modularisé,
qu'il y a plein de include dans tous les sens, et donc des requêtes SQL
dans tous les sens (tout le monde ne pense pas à faire une couche
d'abstraction d'accès aux données) et de tous les côtés, que cela devient
pénible d'ouvrir/fermer partout (faut se trimballer login/mot de passe
partout par exemple - oui je sais on peut faire un include).
Bref, c'est une solution qui marche bien, souvent, mais qui n'est pas
sans conséquences (script plus ``long'' puisque travail supplémentaire de
connexions multiples au cours du script).
Quant à tout repensez de zéro.... hum.... n'est-ce pas le cas de 90% des
applications dans la nature :-) ?
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Pour moi, la véritable solution, pour tout projet de taille importante, c'est d'avoir une couche supplémentaire,
[..]
Si déjà tu fais une couche permanente, autant pousser le principe jusqu'au bout, et faire ton script en FastCGI,
Oui, mais je préfère mod_perl, personnellement, ca va bien plus loin qu'une mise en cache :-) Mais ce n'est pas à mettre en toutes les mains, et ce n'est pas évident pour un hébergeur à faire en mutualisé.
il sera entièrement permanent, ce qui permet de rajouter des caches, de ne faire les tâches d'initialisation qu'au démarrage du script à pas à chaque hit et augmente donc considérablement la vitesse.
Nous sommes tout à fait d'accord.
Par contre, sans FastCGI, et sans couche permanente, il suffit de concentrer au maximum toutes les requêtes à un endroit du script, d'ouvrir la connexion juste avant, et de la fermer juste après. Ca fait l'affaire dans 99% des cas, il faut vraiment avoir un script compliqué pour ne pas avoir la possibilité de faire toutes les requêtes en même temps (dans ce cas il faut en général repenser tout à partir de zéro, c'est qu'il y a un problème, un script web doit impérativement être léger).
Là aussi tout à fait d'accord, ca rejoint ma deuxième itération décrite précédemment.
Il arrive souvent, quand les programmes commencent à être modularisé, qu'il y a plein de include dans tous les sens, et donc des requêtes SQL dans tous les sens (tout le monde ne pense pas à faire une couche d'abstraction d'accès aux données) et de tous les côtés, que cela devient pénible d'ouvrir/fermer partout (faut se trimballer login/mot de passe partout par exemple - oui je sais on peut faire un include).
Bref, c'est une solution qui marche bien, souvent, mais qui n'est pas sans conséquences (script plus ``long'' puisque travail supplémentaire de connexions multiples au cours du script).
Quant à tout repensez de zéro.... hum.... n'est-ce pas le cas de 90% des applications dans la nature :-) ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
