2008-09-08 20 views
42

Estoy usando la capa PDO de PHP para el acceso a datos en un proyecto, y he estado leyendo sobre ello y viendo que tiene un buen soporte innato para conexiones de bases de datos persistentes. Me pregunto cuándo/si debería usarlos. ¿Vería los beneficios de rendimiento en una aplicación CRUD-heavy? ¿Hay inconvenientes a considerar, quizás relacionados con la seguridad?Conexiones de bases de datos persistentes, ¿sí o no?

Si le importa, estoy usando MySQL 5.x.

Respuesta

58

Usted podría utilizar esto como un "conjunto de reglas" en bruto:

, utilizar conexiones persistentes, si:

  • sólo hay unas pocas aplicaciones/usuarios que acceden a la base de datos, es decir, que no lo hará resulta en 200 conexiones abiertas (pero probablemente inactivas), porque hay 200 usuarios diferentes compartidos en el mismo host.
  • La base de datos se está ejecutando en otro servidor que está accediendo a través de la red
  • Un (una) aplicación tiene acceso a la base de datos muy a menudo

NO, no use conexiones persistentes, si:

  • Su aplicación solo necesita acceder a la base de datos 100 veces por hora.
  • Tiene muchos servidores web accediendo a un servidor de base de datos
  • Está utilizando Apache en modo prefork. Utiliza una conexión para cada proceso secundario, que puede aumentar rápidamente. (a través de @Powerlord en los comentarios)

El uso de conexiones persistentes es considerablemente más rápido, especialmente si está accediendo a la base de datos a través de una red. No hace mucha diferencia si la base de datos se ejecuta en la misma máquina, pero aún es un poco más rápida. Sin embargo, como su nombre lo indica, la conexión es persistente, es decir, permanece abierta, incluso si no se utiliza.

El problema es que, en "configuración predeterminada", MySQL solo permite 1000 "canales abiertos" paralelos. Después de eso, se rechazan las conexiones nuevas (puede ajustar esta configuración). Entonces, si tiene, por ejemplo, 20 servidores web con cada 100 clientes en cada uno de ellos, y cada uno de ellos tiene solo un acceso a la página por hora, las matemáticas simples le mostrarán que necesitará 2000 conexiones paralelas a la base de datos. Eso no funcionará

Ergo: Úselo únicamente para aplicaciones con muchas solicitudes.

+1

Además, no use conexiones persistentes si está utilizando Apache en modo prefork.Utiliza una conexión para cada proceso secundario, que puede aumentar rápidamente. – Powerlord

+0

@BlaM, no recibo tu último párrafo. ¿Las conexiones persistentes no le permiten reutilizarlas (ese es todo el punto?) Por lo que no necesita 2000 conexiones, ya que se reutilizarán. ¿O quiere decir que ** cada cliente ** tiene un nombre de usuario único? Aun así, ¿no se cerrarían automáticamente las antiguas conexiones persistentes cuando estén hechas para dar paso a nuevas conexiones? – Pacerier

+0

@Pacerier: me refiero a clientes cada uno con su propio nombre de usuario. En ese caso, las conexiones anteriores ** NO ** se cerrarán para hacer posibles nuevas conexiones, porque el ** límite ** de las conexiones permitidas es gestionado por MySQL y la persistencia de las conexiones se gestiona desde el lado de PHP, por lo que desde PHP finaliza la base de datos simplemente no permite conectarse. No sabe que se alcanzó el límite y que cerrar las conexiones antiguas ayudará. – BlaM

4

Crear conexiones a la base de datos es una operación bastante costosa. Las conexiones persistentes son una buena idea. En el mundo de ASP.Net y Java, tenemos "conexión de conexiones", que es más o menos lo mismo, y también una buena idea.

3

IMO, la verdadera respuesta a esta pregunta es la que mejor funciona para su aplicación. Recomiendo que compares tu aplicación con conexiones persistentes y no persistentes.

Maggie Nelson @Objectively Oriented publicó sobre esto en agosto y Robert Swarthout hizo una publicación de acompañamiento con algunos números duros. Ambas son buenas lecturas.

+2

"Orientación objetiva" El enlace está desactivado. – Pacerier

+1

No me gusta esta respuesta porque la evaluación comparativa a menudo se hace de una manera muy inexacta. Podría verse muy bien con su computadora accediendo a ella en "patrones de acceso que no sean del mundo real" (que es típico de las pruebas). El tiempo es muy importante, al igual que muchas otras condiciones "difíciles de reproducir" que ocurren a menudo en la vida real. Sugeriría que lo pienses bien y lo evites a menos que definitivamente lo necesites. La preoptimización es el primer pecado. –

0

En mi humilde opinión:

Cuando se usa PHP para el desarrollo web, la mayor parte de su conexión será única "en vivo" para la vida de la página de ejecución. Una conexión persistente le costará muchos gastos generales, ya que tendrá que ponerla en la sesión o algo por el estilo.

El 99% de las veces una única conexión no persistente que muere al final de la ejecución de la página funcionará bien.

El otro 1% de las veces, probablemente no deberías usar PHP para la aplicación, y no hay una solución perfecta para ti.

0

Iba a hacer esta misma pregunta, pero en lugar de hacer la misma pregunta nuevamente, solo agregaré algo de información que he encontrado.

También vale la pena señalar que la extensión mysqli nuevo ni siquiera incluye la opción de utilizar conexiones de bases de datos persistentes.

Todavía estoy usando conexiones permanentes en este momento, pero planeo cambiar a no persistente en el futuro cercano.

+0

Esto debería ser un comentario en lugar de una respuesta. – Pacerier

0

En general, necesitará utilizar conexiones no persistentes a veces, y es bueno tener un único patrón para aplicar al diseño de conexión db (siempre que haya relativamente poco beneficio al usar conexiones persistentes en su contexto).

9

En resumen, mi experiencia dice que las conexiones persistentes deben evitarse en la medida de lo posible.

Tenga en cuenta que mysql_close es un no-operation (no-op) para las conexiones que se crean utilizando mysql_pconnect. Esto significa que el cliente no puede cerrar la conexión persistente a voluntad. Dicha conexión será cerrada por el servidor mysqldb cuando no se produce actividad en la conexión por más de wait_timeout. Si wait_timeout es de gran valor (digamos 30 min), entonces el servidor mysql db puede alcanzar fácilmente max_connections limit. En tal caso, mysql db no aceptará ninguna solicitud de conexión futura. Esto es cuando su buscapersonas comienza a sonar.

Con el fin de evitar llegar a max_connections límite, el uso de la conexión persistente necesidad de un cuidadoso equilibrio de las variables ...

1. Number of apache processes on one host 
2. Total number of hosts running apache 
3. wait_timout variable in mysql db server 
4. max_connections variable in mysql db server 
5. Number of requests served by one apache process before it is re-spawned 

lo tanto, utilizar pl conexión persistente después de bastante deliberación. Es posible que no desee invitar a problemas de tiempo de ejecución complejos por una pequeña ganancia que obtiene de la conexión persistente.

+1

Cita necesaria para "mysql_close es un no-operation (no-op) para las conexiones que se crean usando mysql_pconnect". Para mysqli, ciertamente no es un no-op: http://php.net/manual/en/mysqli.persistconns.php – Pacerier

Cuestiones relacionadas