puedo - conexion php mysqli
MySQL-Conexión persistente vs agrupación de conexiones (2)
Para evitar la sobrecarga de establecer una nueva conexión cada vez que se necesita una consulta contra MySQL, hay dos opciones disponibles:
- Conexiones persistentes, mediante las cuales se solicita una nueva conexión, se realiza una verificación para ver si ya hay una conexión ''idéntica'' abierta y, de ser así, úselo.
- La agrupación de conexiones, mediante la cual el cliente mantiene un conjunto de conexiones, de modo que cada subproceso que necesita usar una conexión lo extraiga del grupo y lo devuelva al grupo cuando finaliza.
Entonces, si tengo una aplicación de servidor multiproceso esperada para manejar miles de solicitudes por segundo, y cada hilo necesita lanzar una consulta contra la base de datos, entonces, ¿cuál es una mejor opción?
Desde mi entendimiento, con las conexiones persistentes, todos los hilos en mi aplicación intentarán y usarán la misma conexión persistente a la base de datos porque todos están usando conexiones idénticas. Por lo tanto, se trata de una conexión compartida entre varios subprocesos de aplicaciones, por lo que las solicitudes se bloquearán pronto en el lado de la base de datos.
Si utilizo un mecanismo de agrupación de conexiones, haré que todos los subprocesos de aplicaciones compartan un conjunto de conexiones. Entonces hay menos posibilidades de una solicitud de bloqueo. Sin embargo, con la agrupación de conexiones, ¿debe esperar una aplicación para adquirir una conexión desde el grupo o debe enviar una solicitud sobre las conexiones en el grupo de todos modos en forma de turnos rotativos, y dejar que la cola, en su caso, suceda en la base de datos?
En cuanto a su pregunta sobre si el servidor de aplicaciones espera una conexión, la respuesta es sí.
Las conexiones de MySQL son bloqueantes Cuando emite una solicitud del servidor MySQL a través de una conexión, la conexión esperará, inactiva, hasta que se reciba una respuesta del servidor.
No hay forma de enviar dos solicitudes en la misma conexión y ver qué devuelve primero. Solo puede enviar una solicitud a la vez.
Por lo tanto, generalmente, un único hilo en un grupo de conexiones consta de una conexión del lado del cliente (en su caso, el servidor de la aplicación es el cliente) y una conexión del lado del servidor (base de datos).
Su aplicación debe esperar un subproceso de conexión disponible desde el grupo, lo que permite que el grupo crezca cuando sea necesario, y reducir el número predeterminado de subprocesos, cuando está menos ocupado.
Tener conexiones persistentes no implica que todos los hilos usen la misma conexión. Simplemente "dice" que mantienes la conexión abierta (en contradicción para abrir una conexión cada vez que la necesites). Abrir una conexión es una operación costosa, por lo que, en general, intenta evitar la apertura de las conexiones más a menudo de lo necesario.
Esta es la razón por la cual las aplicaciones multiproceso a menudo usan grupos de conexiones. El grupo se encarga de abrir y cerrar las conexiones y cada subproceso que necesita una conexión solicita uno del grupo. Es importante tener cuidado de que el hilo devuelva la conexión lo antes posible al grupo, para que otro hilo pueda usarla.
Si su aplicación tiene solo unos pocos hilos largos que necesitan conexión, también puede abrir una conexión para cada hilo y mantenerla abierta.
Usar solo una conexión (como la describió) es igual a un grupo de conexiones con el tamaño máximo uno. Esto tarde o temprano será su cuello de botella ya que todos los hilos tendrán que esperar la conexión. Esta podría ser una opción para serializar las operaciones de la base de datos (realizarlas en un orden determinado), aunque hay mejores opciones para garantizar la serialización.