[Php-avanzado] recordando conceptos---Conexiones persistentes MySQL-- me convienen ? cuando?

Rama Gonzalo ramagonzalo en yahoo.com.ar
Mie Sep 1 15:07:11 ART 2010 

  Gracias Leo, Gracias Matias, muy buena toda la info, muchas cosas a 
probar, voy a comenzar, luego les comentaré.

Saludos!

> Hola, Gonzalo.
>
> El tema de la optimización de la DB no es nada trivial ni simple.
>
> Los problemas, como decis, vienen de varios lugares. Algunos 
> importantes son: la capacidad del server, la configuración del motor, 
> la calidad de las consultas y el buen uso de los indices.
>
> Si tenes ganas de meterte con los tres últimos puntos:
>
> Para empezar bajate mysqltuner.pl <http://mysqltuner.pl>, dale 
> permisos y ejecutalo (necesitás el usuario y pass del admin del motor 
> mysql). Es un script que analiza tu configuración de mysql y compara 
> con las estadísticas del motor para decirte que valores se pueden 
> mejorar. Te lo bajas con:
>
> wget mysqltuner.pl <http://mysqltuner.pl>
>
>
> Por otro lado, hay consultas que le exigen muchos recursos a la db. 
> Por ejemplo, las consultas con ORDER BY RAND() son muy intensivas para 
> el motor, por el modo de funcionar de las mismas. Con tablas medio 
> chicas (unos 300 registros) en un server no muy importante se nota 
> mucho la diferencia.
>
> Otra cosa, intentá no usar funciones en el server para hacer las 
> comparaciones/ordenamientos. Por ejemplo, haciendo un buscador, 
> necesitaba calcular la distancia de Levenstein (un valor que te da la 
> diferencia entre dos palabras, sirve para hacer el "Quizás quiso 
> decir..."). Probé con una función en el motor, trayendo las 3 palabras 
> mas similares y probé trayendo todo el diccionario (unas 3000 
> palabras) y calculando la distancia con php. La última opción resultó 
> mucho más rápida y menos intensiva para el procesador.
>
>
> Otro de los problemas que podés tener de rendimiento en las 
> consultas (y para mi uno de los más importantes) es el uso de los 
> índices. Una consulta que busca un registro en una tabla sin índices 
> puede tener que recorrer toda la tabla. Con el ratio de inserciones 
> que tenés, calculo que tus tablas no debe ser chicas. Esto es una 
> patada al server.
>
> Para detectar consultas que no tienen índices podés activar el "mysql 
> slow query log" en el archivo de configuración my.cnf.
> Esta es mi config (para la version 5.1.43, para versiones anteriores 
> fijate en el manual o en la pagina de mysql porque algunas son distintas):
> log_slow_queries = /usr/local/mysql/data/mysql-slow.log
> long_query_time = 5
> log-queries-not-using-indexes
>
> El archivo lo podés analizar con:
> mysqldumpslow -t 10 /usr/local/mysql/data/mysql-slow.log
>
> Eso te va a dar las 10 consultas que más tiempo tarden en ejecutarse. 
> Buscá otros parámetros en la ayuda del programa, para ver las 
> consultas que más se ejecutan, etc.
>
> Una vez que tengas la consulta que te interesa, podés usar la 
> sentencia EXPLAIN de mysql y ver la salida. Por ejemplo, vamos a tomar 
> una consulta:
> SELECT notas.*,usuarios.username FROM notas JOIN usuarios ON 
> usuarios.id <http://usuarios.id>=notas.id_usuario LIMIT 10
> Para analizarla, ejecutaríamos:
> EXPLAIN SELECT notas.*,usuarios.username FROM notas JOIN usuarios ON 
> usuarios.id <http://usuarios.id>=notas.id_usuario LIMIT 10
>
> El resultado es algo así (en el mail se va a ver feo, miralo por 
> pantalla o copialo-pegalo y acomodá las lineas):
> +----+-------------+-------------+--------+---------------+---------+---------+----------------------------------------------+------+-------+
> | id | select_type | table       | type   | possible_keys | key     | 
> key_len | ref                                          | rows | Extra |
> +----+-------------+-------------+--------+---------------+---------+---------+----------------------------------------------+------+-------+
> |  1 | SIMPLE      | comentarios | ALL    | NULL          | NULL    | 
> NULL    | NULL                                         |  192 |       |
> |  1 | SIMPLE      | usuarios    | eq_ref | PRIMARY       | PRIMARY | 
> 4       | hispabodas_hispabodas.comentarios.id_usuario |    1 |       |
> +----+-------------+-------------+--------+---------------+---------+---------+----------------------------------------------+------+-------+
> En esta respuesta el server nos dice las tablas que se consultaron, el 
> orden en que se consultan, los posibles índices a usar, los que se 
> usaron, la referencia del indice a otras tablas, la cantidad de 
> registros que se consultaron de la tabla e información extra.
>
> Con todos estos datos podés analizar un poco mejor la consulta, saber 
> cómo la ve el motor y optimizarla.
>
> Como comentario final, acordate que cada índice que agregues a la 
> tabla la hace más rápida al consultar, pero más lenta al 
> insertar/eliminar/modificar. No te excedas con los índices que no se 
> usan porque puede ser contraproducente.
>
> Con esto vas a poder optimizar algunas consultas, por lo menos las que 
> más consumen. Después de dejar todo 10 puntos, vas a tener que meterte 
> con otras opciones, como te decía Leo. El caché es una muy buena 
> opción. A mi me bajó el uso del procesador por parte del motor del 80% 
> (antes del cache) al 20% (despues del cache).
>
> Yo no usaría conexiones persistentes, por todo lo que te dijo Leo.
>
> Lo que si deberías hacer es (si usás php-mysql) usar la librería 
> mysqli (no la mysql) que está más optimizada para motores nuevos (a 
> partir de 5.0).
>
> Estoy a punto de escribir algo un poco más detallado sobre esto. 
> Cuando tenga tiempo lo haré.
>
> Cualquier cosa avisá y reportá resultados.
>
> Saludos, Matias.
>
>
> El 31 de agosto de 2010 18:17, Leonardo Tadei - Pegasus Tech Supply 
> <leonardot en pegasusnet.com.ar <mailto:leonardot en pegasusnet.com.ar>> 
> escribió:
>
>     Hola Gonzalo,
>
>     El mar, 31-08-2010 a las 06:34 -0300, Rama Gonzalo escribió:
>     > Hola, tengo una DB con algo mas de 140 consultas y 10 inserciones
>     > aprox. por segundo (usuarios diferentes) y tengo problemas en el
>     > rendimientos, desde ya que se puede deber a mil cosas, pero quisiera
>     > saber si las conexiones persistentes me pueden ayudar a mejorar
>     un poco
>     > o complicaría más la cosa.
>     > Y en que casos en conveniente y en cuales no.
>
>            Casi nunca convienen las conexiones persistentes, y sobre
>     todo, no son
>     aplicables cuando los usuarios de la DB son distintos.
>            Si implementás conexiones persistentes, tenés que tener
>     mucho, pero
>     mucho cuidado de cerrarlas correctamente, porque si no se te cae el
>     server por demasiadas conexiones abiertas.
>
>            Para este caso, tal vez te convenga más implementar un
>     sistema de
>     caché, para que las 140 consultas bajen a la misma cantidad que
>     tenés de
>     inserciones.
>
>            Después, el paso que sigue son tablas en RAM, y bajarlas a
>     disco cada
>     tanto, y de ahí pasás a clusterizar el almacenamiento o pasarte a
>     DB no
>     relacionales, que según dicen pero yo no probé, tienen muy buen
>     rendimiento bajo estos escenarios, aunque en el camino perdés la
>     consistencia automática de los almacenamientos.
>
>     > Muchas gracias.
>
>            Por nada!
>
>     --
>
>     Leonardo Tadei
>     leonardot en pegasusnet.com.ar <mailto:leonardot en pegasusnet.com.ar>
>     http://blog.pegasusnet.com.ar
>     Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
>     _______________________________________________
>     Php-avanzado mailing list
>     Php-avanzado en pato2.fi.mdp.edu.ar
>     <mailto:Php-avanzado en pato2.fi.mdp.edu.ar>
>     http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
>
>
>
> -- 
> Matias Fernando Gea
> matigea en gmail.com <mailto:matigea en gmail.com>
> http://www.mfgea.com.ar
>
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado

Más información sobre la lista de distribución Php-avanzado