[Php-avanzado] recordando conceptos---Conexiones persistentes MySQL-- me convienen ? cuando?
Matias Gea
matigea en gmail.com
Vie Sep 10 09:27:00 ART 2010
Hola, Gonzalo.
Esta es una opcion para que el motor no ejecute dos búsquedas. La técnica es
marcar con un flag los registros que quieras y despues ordenar por ese flag
(en este caso, el flag está invertido, a los idiomas que selecciona el
usuario se le asigna un cero y al resto un uno).
Hay que ver cómo rinde con el tema de los índices, porque al generar el flag
al vuelo el motor debe usar una tabla temporal para ordenar.
SELECT text.id,text.text, IF(app.lang_id IN(N,N,N,N,N),0,1) AS orden
FROM app,text
WHERE text.app_id=app.id
AND text.status = "S"
AND (app.fb_appid=N OR (app.status="S" AND app.deleted=N))
ORDER BY orden,text.created DESC
LIMIT N,N
Probala y avisá.
Saludos!
El 10 de septiembre de 2010 01:57, Rama Gonzalo
<ramagonzalo en yahoo.com.ar>escribió:
> La verdad. que me acabo de dar cuenta.. muchas animalas.. muy buenas
> estas hermientas.. aun estoy en los primeros pasos de optimización, pero
> bueno.. ejemplo.. teníamos una consulta que demoraba casi 120
> segundos..(si si.. ) con poner solo un índice paso a 2 segundos.. ahora
> es solo una animaladita :).
>
> ------- analizando el log con mysqldumpslow, entre una de las primeras
> aparece esta ----------------
> Count: 36 Time=0.56s (20s) Lock=0.00s (0s) Rows=15.0 (540),
> (
> SELECT text.id,text.text FROM app,text WHERE
> text.app_id=app.id AND text.status = "S" AND (app.fb_appid=N OR
> (app.status="S" AND app.deleted=N)) AND app.lang_id IN(N,N,N,N,N) ORDER
> BY text.created DESC LIMIT N)
> UNION
> (
> SELECT text.id,text.text FROM app,text WHERE
> text.app_id=app.id AND text.status = "S" AND (app.fb_appid=N OR
> (app.status="S" AND app.deleted=N)) AND app.lang_id NOT IN(N,N,N,N,N)
> ORDER BY text.created DESC LIMIT N)
> LIMIT N,N
> --------------------------------------------
> Según mi análisis esta demorando casi 1 segundo, así tengo varias.
> Lo que quisiera preguntarles es ¿cómo se podría mejorar la consulta?.
> Tengo un listado de textos en varios idiomas,dialectos, y necesito
> listar primero todos los de habla hispana(o el que fuese solicitado por
> el user) es_ES, es_LA, es_CO , etc y luego el resto.. por lo tanto lo
> primero que se nos ocurrío fue hacer un UNION tomando sólo los de ese
> idioma y luegos todos menos los de ese idioma.., desde un comienzo lo
> ví medio vestía, pero no me dieron para más los conocimientos si lo
> quería hacer todo en una misma consulta SQL sin mechar con PHP.
>
> ¿Qué alternativas tengo en esta consulta?
>
>
> Mil gracias.. muy buenos ambos aportes.
>
>
>
> > 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
>
> _______________________________________________
> 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/20100910/6bd6078e/attachment.htm
Más información sobre la lista de distribución Php-avanzado