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

Mie Sep 1 09:06:00 ART 2010

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, 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

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=notas.id_usuario
LIMIT 10
Para analizarla, ejecutaríamos:
EXPLAIN SELECT notas.*,usuarios.username FROM notas JOIN usuarios ON
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> 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
> 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
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>

-- 
Matias Fernando Gea
matigea en gmail.com
http://www.mfgea.com.ar
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20100901/268acecf/attachment-0001.htm 