Yo uso perezoso conexión para conectarme a mi base de datos dentro de mi DB objeto. Básicamente, esto significa que no llame a mysql_connect() hasta la primera consulta se le entregaron, y posteriormente se omite la reconexión desde luego, en después de.

Ahora tengo un método en mi DB clase llamada disconnectFromDB() que prácticamente llamadas mysql_close() y establece $_connected = FALSE (por lo que el query() método para conectarse a la DB). Debería esto ser llamado después de cada consulta (como una función privada) o externamente a través de los objetos… porque yo estaba pensando en algo como (el código es sólo un ejemplo)

$students = $db->query('SELECT id FROM students');

$teachers = $db->query('SELECT id FROM teachers');

Ahora si que se cierre después de cada consulta, ¿se ralentiza mucho, ya que se opuso a mí me acaba de añadir esta línea al final

$db->disconnectFromDB();

O debo incluir que la línea de arriba al final de la página?

¿Qué ventajas/desventajas de hacerlo tienen? Lo que ha funcionado mejor en su situación? No hay nada realmente mal con olvido de cerrar la conexión de mySQL, además de una pequeña pérdida de rendimiento?

Agradezco que se tome su tiempo para responder.

Gracias!

  • Es de esperar que su aplicación es mejor con particiones de tus ejemplos sugieren. Sería más fácil seguir la pista de su perezoso conexión si se encapsula.
InformationsquelleAutor alex | 2008-12-03

6 Comentarios

  1. 24

    Que yo sepa, a menos que el uso de conexiones persistentes, MySQL, se cerrará la conexión al final de la página de ejecución.

    Por lo tanto, llamar a desconectar no añadirá nada y porque no el perezoso de conexión, puede causar una segunda conexión se pueden crear si usted u otro programador comete un error y se desconecta en el momento equivocado.

    Dado que, sólo quiero que mi conexión se cierra automáticamente para mí. Sus páginas se deben ejecutar de forma rápida, por lo tanto, la celebración de la conexión para que la pequeña cantidad de tiempo no debe causar problemas.

    • +1 a dejar PHP limpiar las conexiones (no recomiendo el uso de conexiones persistentes).
    • También se recomienda contra el uso de conexiones persistentes. Ellos me han hecho nada más que problemas y difícil de localizar errores en el pasado.
    • También me gustaría recomendar que baje el wait_timeout configuración de MySQL. El valor predeterminado es 8 horas. La mayoría de las páginas web no tomar mucho tiempo para cargar.
    • la mayoría de los? ninguno de ellos tiene 8 horas para cargar 😛
  2. 5

    Acabo de leer este comentario en el sitio web de PHP con respecto a la conexión persistente y puede ser muy interesante, a saber:

    Aquí es un resumen de los motivos más importantes
    NO usar conexiones persistentes:

    • Al bloquear una tabla, normalmente se desbloquea cuando la conexión
      se cierra, pero desde persistente
      las conexiones no se cierran, las tablas
      usted accidentalmente deja bloqueado se
      permanecen bloqueados, y la única manera de
      desbloqueo de ellos es esperar a que el
      conexión de tiempo de espera o matar a los
      proceso. El mismo problema de bloqueo de
      ocurre con las transacciones. (Ver
      comentarios sobre el 23-Abr-2002 &
      12-Jul-2003)

    • Normalmente tablas temporales se quitan cuando se cierra la conexión,
      pero ya que las conexiones persistentes hacer
      no cerrar, tablas temporales no son tan
      temporal. Si no explícitamente
      colocar las tablas temporales cuando se
      hecho, que la tabla ya existe
      para un nuevo cliente de la reutilización de la misma
      conexión. El mismo problema se produce
      con la configuración de las variables de sesión. (Ver
      comentarios sobre el 19-Nov-2004 &
      07-Aug-2006)

    • Si PHP y MySQL están en el mismo servidor o de la red local, la
      el tiempo de conexión puede ser insignificante, en
      cuyo caso no hay ninguna ventaja para
      las conexiones persistentes.

    • Apache no funciona bien con las conexiones persistentes. Cuando
      recibe una solicitud de un cliente nuevo,
      en lugar de usar uno de los
      los niños que ya tiene una
      conexión persistente abierto, tiende
      para generar un nuevo hijo, el que luego debe
      abrir una nueva conexión de base de datos. Este
      causas el exceso de procesos que son sólo
      para dormir, desperdicio de recursos, y
      causando errores cuando llegue a su
      el número máximo de conexiones, además de que las derrotas
      cualquier beneficio de conexiones persistentes.
      (Ver los comentarios de abajo de 03-Feb-2004,
      y la nota de pie de página en
      http://devzone.zend.com/node/view/id/686#fn1)

    (Yo no era el que escribió el texto de arriba)

    • Żde donde viene? La copia de otros lugares sin tanta como cita no es correcta.
    • No hay información construida sobre fondo fecha de salida de las versiones de mysql en allí. Me gustaría ver escépticamente. También con respecto a PHP.
    • Además de las tablas temporales, no te olvides de MySQL variables de usuario, la configuración de la sesión como CARACTERES, y LAST_INSERT_ID(). Estos se encuentran en el ámbito de la conexión, así que la próxima solicitud web que consigue que la persistencia de la conexión puede «ver» el estado de otro usuario de la DB de la sesión!
    • Para agregar a lo que Bill Karwin, dijo, hay también un ajuste en algún lugar en mysqli para activar el seguimiento de depuración en el que se incluye en el ámbito de la conexión. No lo he utilizado en un tiempo, pero el efecto fue algo a lo largo de las líneas de enviar el texto completo de cada consulta directamente al navegador de salida.
    • Andrew Medico: me dijo que yo no lo escribí yo y que me sacó desde el sitio web de PHP. Así que, ¿cuál es el problema? Si usted realmente desea el enlace: us2.php.net/manual/en/function.mysql-pconnect.php#85670
    • Es una mezcla de cinco-año-viejo comentarios de los usuarios a una nota en el manual de PHP acerca de MyISAM comportamiento. Busco la información más reciente más cerca de la fuente.
    • Los dos primeros me leen como «si escribes código espagueti, conexiones persistentes pueden convertirse en un problema». De la OMI, eso significa que la solución correcta es «no hay que escribir código espagueti», no «no usar conexiones persistentes».

  3. 5

    No te molestes en desconectar. El costo de la comprobación de $_connected antes de cada consulta combinada con el costo de la realidad, se llama $db->disconnectFromDB(); para hacer el cierre va a terminar siendo más caro que simplemente dejar de PHP cerrar la conexión cuando haya terminado con cada página.

    Razonamiento:

    1: Si usted dejar la conexión abierta hasta el final de la secuencia de comandos:

    • Motor de PHP bucles a través de la matriz interna de las conexiones de mysql
    • Motor de PHP llamadas mysql_close() internamente para cada conexión

    2: Si cierra la conexión de sí mismo:

    • Usted tiene que comprobar el valor de $_connected para cada consulta. Esto significa que PHP tiene que verificar que la variable $_connected A) existe B) es un valor booleano y C) es verdadero/falso.
    • Usted tiene que llamar a su ‘desconectar’ la función, y la función de las llamadas son uno de los más caros de operaciones en PHP. PHP tiene que comprobar que su función: a) existe, B) no es privado o protegido y C) que proporcionó argumentos suficientes para su función. También tiene que crear una copia de la $relación de la variable en el nuevo ámbito local.
    • Entonces su ‘desconectar’ la función de llamada mysql_close (), lo que significa PHP A) comprueba que mysql_close() existe y B) que usted ha proporcionado todos los argumentos necesarios para mysql_close() y C) que son del tipo correcto (mysql recursos).

    Podría no ser 100% correcto aquí, pero creo que las probabilidades están a mi favor.

    • altamente especulativo afirmaciones.
    • ¿Piensas que es incorrecto?
    • Sí. PHP se va a necesitar para hacer la misma comprobación y la misma llamada, y que ha expuesto el sistema para la conexión abierta restricción más de lo necesario. (Y estéticamente, es descuidado, pero ese es otro asunto.)
    • ¿Cuál es tu sugerencia doofledorfer… de la zanja de la desconexión, pero dejar la pereza conector? Eso es lo que yo he en la actualidad.
    • Creo que estás bien. No estoy de acuerdo con la lógica que se utiliza en esta respuesta. Respuesta correcta, sin apoyo (y no del todo creíbles) razonamiento.
  4. 1

    La unidad básica de ejecución, presumiblemente, es toda una secuencia de comandos. Lo primero de todo son ganas de aplicar los recursos (es decir, la base de datos) para, de manera eficiente y eficaz, es la totalidad de una única secuencia de comandos.

    Sin embargo, PHP, Apache/IIS/lo que sea, tiene vida propia; y que son capaces de usar las conexiones de abrir más allá de la vida de la secuencia de comandos. Esa es la importancia de la persistencia (o agrupado) conexiones.

    De nuevo a la secuencia de comandos. Resulta que tengo una gran oportunidad para ser creativo sobre el uso de la conexión durante su ejecución.

    El típico ingenuo script tienden a golpear la conexión de nuevo y de nuevo, recoger localmente apropiada de los pedazos de los datos asociados a los objetos dados/modules/opciones seleccionadas. Aquí es donde la metodología de procedimiento puede infligir una pena que la conexión abriendo, pedir, recibir, y cierre. (Tenga en cuenta que cualquier consulta única que sigue viva hasta que se cierra en forma explícita, o el script finaliza. Tenga cuidado de que una conexión y una consulta no son la misma cosa en todos. Consultas de atar tablas; las conexiones de atar … conexiones (en la mayoría de los casos asignados a sockets). Así que usted debe ser consciente de una adecuada economía en el uso de ambos.

    El más económico de la estrategia con respecto a las consultas es tener tan pocos como sea posible. Voy a menudo a tratar de construir una más o menos complejo, se unió a la consulta que trae un conjunto completo de datos en lugar de reparto de las solicitudes en trozos pequeños.

  5. 1

    El uso de un perezoso conexión es probablemente una buena idea, ya que puede que no necesite la conexión de base de datos para algunas ejecuciones del script.

    Por otro lado, una vez abierto, deja abrir y cerrar explícitamente como finalice la secuencia de comandos, o permitir PHP para limpiar la conexión – tener una conexión abierta no va a dañar nada, y no quiere incurrir en la sobrecarga innecesaria de comprobar y volver a establecer una conexión si se consulta la base de datos una segunda vez.

Dejar respuesta

Please enter your comment!
Please enter your name here