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
123
124
125
126
127
|
<?xml version="1.0" encoding="iso-8859-1"?>
<chapter id="features.persistent-connections">
<title>Conexiones persistentes a bases de datos</title>
<simpara>
Las conexiones persistentes son enlaces SQL que no se cierran
cuando termina la ejecución del archivo de comandos.
Cuando se pide una conexión persistente, PHP comprueba
si hay ya una conexión persistente idéntica (que
permanecía abierta desde antes) - y si existe, la usa.
Si no existe, crea un enlace. Una conexión 'idéntica'
es una conexión que se abrió hacia el mismo "host", con
el mismo nombre de usuario y la misma contraseña (donde sea
aplicable).</simpara>
<simpara>
La gente que no está familiarizada con el modo como trabajan
y distribuyen la carga los servidores "web" puede confundir que
persistente significa lo que no es. En particular, ellas
<emphasis>no</emphasis> te dan la habilidad de abrir
'sesiones de usuario' en el mismo enlace SQL,
<emphasis>no</emphasis> dan la habilidad de construir una
transacción de forma eficiente, y no hacen un montón de
otras cosas. De hecho, para ser extremadamente claros sobre el tema
las conexiones persistentes no te dan <emphasis>ninguna</emphasis>
functionalidad que no fuera posible con sus hermanas
no-persistentes.</simpara>
<simpara>
¿Por qué?</simpara>
<simpara>
Esto tiene que ver con el modo como funcionan los servidores "web".
Hay tres modos en que un servidor "web" puede utilizar PHP para generar
páginas web.</simpara>
<simpara>
El primer método es usar PHP como una capa CGI. Cuando corre
de este modo, se crea y destruye una instancia del intérprete
PHP por cada página solicitada (para una página PHP)
a tu servidor. Debido a que se destruye después de cada
petición, cualquier recurso que adquiera (como un enlace a un
servidor de base de datos SQL) se cierra cuando es destruido. En
este caso, no se gana nada si se intentan usar conexiones persistentes.
</simpara>
<simpara>
El segundo, y más popular, método es correr PHP como
un módulo en un servidor web multiproceso, lo cual actualmente
sólo incluye Apache. Un servidor multiproceso tiene
típicamente un proceso (el padre) que coordina un conjunto de
procesos (sus hijos) que realmente hacen el trabajo se servir las
páginas web. Cuando entra cada petición de un cliente,
es entregada a uno de los hijos que no esté ya sirviendo a
otro cliente. Esto significa que cuando el mismo cliente hace una
segunda petción al servidor, puede ser atendidp por un proceso
hijo distinto del de la primera vez. Lo que una conexión persistente
hace por ti en este caso es hacerlo de tal modo que cada proceso hijo
sólo necesita conectar a tu SQL server la primera vez que sirve
una página que hace uso de una conexión así. Cuando
otra página solicita una conexión a SQL server, puede
reutilizar la conexión que el hijo estableció previamente.
</simpara>
<simpara>
El último método es usar PHP como un "plug-in" para un
servidor web multihilo. En la actualidad es solamente teórico --
PHP no funciona aún como "plug-in" para ningún servidor
web multihilo. Hay trabajo en progreso para soportar ISAPI, WSAPI y
NSAPI (en Windows), lo cual permitirá a PHP ser utilizado como
"plug-in" para servidores web multihilo como Netscape FastTrack,
Internet Information Server (IIS) de Microsoft, y O'Reilly's WebSite Pro.
Cuando esto ocurra, el comportamiento será exactamente el mismo
que para el modelo de multiprocesador descrito anteriormente.</simpara>
<simpara>
Si las conexiones persistentes no aportan ninguna funcionalidad
añadida, ¿para qué son buenas?</simpara>
<simpara>
La respuesta aqui es extremadamente simple -- eficiencia. Las conexiones
persistentes son buenas si las cabeceras de control para crear un enlace
a tu servidor SQL es alta. Que estas cabeceras sean o no realmente altas
depende de muchos factores. Como, qué clase de base de datos es, si
esta o no situada en el mismo ordenador que el servidor web, cómo
está de cargada la máquina donde se encuentre el servidor
SQL, y otras así. El hecho fundamental es que si la cabecera de
conexión es alta, las conexiones persistentes te ayudan
considerablemente . Ellas hacen que el proceso hijo simplemente conecte
solamente una vez durante todo su intervalo de vida, en vez de
cada vez que procesa una pagina que requiere conectar al servidor SQL.
Esto significa que por cada hijo que abrió una conexión
persistente tendrá su propia conexión persistente al servidor.
Por ejemplo, si tienes 20 procesos hijos distintos que corran un
archivo de comandos que cree una conexión persistente a tu
servidor SQL, tendrías 20 conexiones diferentes a ti servidor
SQL, una por cada hijo.</simpara>
<simpara>
Un resumen importante. Las conexiones persistentes fueron diseñadas
para tener una equivalencia uno-a-uno con las conexiones normales.
Eso significa que deberís <emphasis>siempre</emphasis> ser capaz
de reemplazar las conexiones persistentes por conexiones no persistentes
y no cambiará, el modo como se comporta el archivo de comandos.
<emphasis>Puede</emphasis> cambiar la eficiencia del archivo de comandos
(y probablemete lo hará), ¡pero no su comportamiento!
</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:
-->
|
