Persistente vs no persistente - ¿Qué debería usar?

Question

Mi sitio siempre ha usado conexiones persistentes, según mi comprensión de ellas, no hay ninguna razón para no hacerlo. ¿Por qué cerrar la conexión cuando se puede reutilizar? Tengo un sitio que tiene acceso total a aproximadamente 7 bases de datos. No es un gran sitio de tráfico, pero es lo suficientemente grande. ¿Cuál es tu opinión sobre persistente, debería usarlos?

Answer 1

Con conexiones persistentes:

• No se puede construir el procesamiento de transacciones efectivamente
• sesiones de usuario imposibles en la misma conexión
• aplicación no son escalables. Con el tiempo puede necesitar extenderlo y requerirá administración/seguimiento de conexiones persistentes
• si el script, por cualquier razón, no pudo liberar el bloqueo en la tabla, entonces los siguientes scripts se bloquearán indefinidamente y uno debe reiniciar el servidor db El uso de transacciones, bloque de transacción también pasará a la siguiente secuencia de comandos (usando la misma conexión) si la ejecución del script termina antes de que el bloque de transacción se completa, etc.

Las conexiones persistentes no aportan nada se puede hacer con conexiones no persistentes .
Entonces, ¿por qué usarlos, en absoluto?
La única razón posible es el rendimiento, para usarlos cuando la sobrecarga de crear un enlace a su servidor SQL es alta. Y esto depende de muchos factores como:

• base de datos de tipo
• si el servidor MySQL está en la misma máquina y, si no, ¿hasta dónde? podría estar fuera de su red/dominio local?
• cuánto sobrecargado por otros procesos de la máquina sobre la que se asienta MySQL

Uno siempre puede reemplazar las conexiones persistentes por conexiones no persistentes. Puede cambiar el rendimiento del script, pero no su comportamiento.

Comercial RDMS podría ser licenciado por el número de conexiones abiertas simultáneas y aquí las conexiones persistentes puede misserve

Answer 2

Mi conocimiento sobre el área es un tanto limitado, así que no puedo darle muchos detalles sobre el tema pero, hasta donde yo sé, el proceso de crear conexiones y entregarlas a un hilo realmente cuesta recursos, así que lo haría evítalo si fuera tú. De todos modos, creo que la mayoría de estas decisiones no se pueden generalizar y dependen del negocio.

Si, por ejemplo, su aplicación se comunica continuamente con la base de datos y solo se detendrá cuando se cierre la aplicación, entonces quizás las conexiones persistentes sean el camino a seguir, ya que evita el proceso mencionado anteriormente.

Sin embargo, si su aplicación solo se comunica con la base de datos esporádicamente para obtener información menor, cerrar la conexión puede ser más sensato, ya que no desperdiciará recursos en conexiones abiertas que no están siendo utilizadas.

También hay una técnica llamada "Pooling de conexiones", en la que se crean a priori una serie de conexiones y se mantienen allí para que consuman otras aplicaciones. En este caso, las conexiones son persistentes para la base de datos pero no persistentes para las aplicaciones.

Nota: Las conexiones en MSSQL siempre son persistentes en la base de datos porque la agrupación de conexiones es el comportamiento predeterminado.