1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.7 $ -->
<chapter id="features.persistent-connections">
<title>Connexions persistantes aux bases de données</title>
<simpara>
Les connexions persistantes aux bases de données SQL sont
des connexions qui ne se referment pas à la fin du script.
Lorsqu'une connexion persistante est demandée, PHP s'assure
qu'il n'y a pas une autre connexion identique (qui serait ouverte
précédemment, avec le même nom d'hôte,
d'utilisateur et le même mot de passe), et si une telle connexion
existe, elle est utilisée. Sinon, elle est créée.
Une connexion identique est une connexion qui a ouvert le même
hôte, avec le même nom et le même mot de passe (s'ils
sont nécessaires).
</simpara>
<simpara>
Ceux qui ne sont pas rompus aux techniques des serveurs web et leur
distribution de la charge de travail, se font parfois une fausse
idée de ces connexions persistantes. En particulier,
les connexions persistantes ne permettent pas l'ouverture de plusieurs
sessions avec le même lien, ne permettent pas la réalisation
de transactions efficaces et ne font pas le café. En fait,
pour être extrêmement clair sur le sujet, les
connexions persistantes ne vous donnent aucune fonctionnalité
de plus que les connexions non persistantes.
</simpara>
<simpara>
Alors pourquoi les connexions persistantes?
</simpara>
<simpara>
Cela s'explique par la manière avec laquelle les serveurs web
fonctionnent. Il y a trois manières d'utiliser PHP pour
générer des pages.
</simpara>
<simpara>
La première est d'utiliser PHP comme un CGI (Common Interface Gateway).
Lorsque PHP fonctionne de cette manière, une instance de
l'interpréteur PHP est créée puis détruite
pour chaque page demandée. Etant donné que cet interpreteur est
détruit après chaque requête, toutes les
ressources acquises (comme une connexion à une base SQL),
sont purement et simplement détruites.
</simpara>
<simpara>
La deuxième méthode, et de loin, la plus prisée,
est d'exécuter PHP sous la forme d'un module sur un serveur
multi-processus, ce qui revient à dire : Apache. Un tel serveur
a typiquement un processus parent qui coordonne un ensemble de processus fils,
qui servent les fichiers. Lorsque les requêtes parviennent depuis
un client, elles sont transmises à un fils disponible. Cela signifie
que si un client fait une deuxième requête, il peut
être servi par un processus client différent du premier.
Les connexions persistantes vous permettent alors de ne vous connecter
à une base SQL que la première fois. Lors des connexions
ultérieures, les processus fils pourront réutiliser la
connexion ouverte précédemment.
</simpara>
<simpara>
La dernière méthode est d'utiliser PHP sous la forme d'un
module de serveur multi-threads. Actuellement, PHP 4 supporte
ISAPI, WSAPI, et NSAPI (sous Windows), qui permettent tous d'utiliser
PHP comme un module sur un serveur multi-threads tel que Netscape
FastTrack (iPlanet), Microsoft's Internet Information Server (IIS), et
O'Reilly's WebSite Pro. Le comportement est essentiellement le même
que pour les serveurs multi-processus décrits précédemment.
Notez que SAPI n'est pas disponible avec PHP 3.
</simpara>
<simpara>
Si les connexions persistantes n'ont aucune fonctionnalité de plus,
à quoi servent-elles?
</simpara>
<simpara>
La réponse est extrêmement simple : efficacité. Les
connexions persistantes sont un bon moyen d'accélérer les
accès à une base SQL si le traitement de connexion à
la base est long. Ce temps dépend de nombreux facteurs : le type
de base de données, cette base est-elle sur le même serveur
ou pas, quelle est la charge du serveur de base de données, etc...
Si le temps de connexion est long, les connexions persistantes seront
bien utiles, car une fois ouverte par un processus fils, la connexion est
réutilisable sans avoir à se reconnecter. Si vous avez 20
processus fils, il suffit d'avoir 20 connexions persistantes ouvertes,
une par fils.
</simpara>
<simpara>
Notez que les connexions persistantes ont quelques inconvénients
si vous hébergez une base de données, dont le nombre maximal de
connexion risque d'être atteint par les connexions persistantes.
Si votre base de données accepte jusqu'à 16 connexions
simultanées et que, 17 processus essaient de se connecter,
le dernier restera sur la touche. S'il y a des erreurs dans les scripts qui ne permettent
pas de fermer la connexion (par exemple, une boucle infinie), votre
serveur sera rapidement engorgé. Vérifiez la documentation de votre
base de données pour savoir comment elle traite les connexions
inactives ou abandonnées.
</simpara>
<simpara>
Résumons-nous : les connexions persistantes ont été
définies pour avoir les mêmes fonctionnalités que
les connexions non persistantes. Les deux types de connexions
sont parfaitement interchangeables, et n'affecteront pas le
comportement de votre script : uniquement son efficacité.
</simpara>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
|
