Hola, Gonzalo.<div><br></div><div>El tema de la optimización de la DB no es nada trivial ni simple.</div><div><br></div><div>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.</div>
<div><br></div><div>Si tenes ganas de meterte con los tres últimos puntos:</div><div><br></div><div>Para empezar bajate <a href="http://mysqltuner.pl">mysqltuner.pl</a>, 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:</div>
<div><br></div><div>wget <a href="http://mysqltuner.pl">mysqltuner.pl</a></div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>Para detectar consultas que no tienen índices podés activar el "mysql slow query log" en el archivo de configuración my.cnf.</div>
<div>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):</div><div>log_slow_queries = /usr/local/mysql/data/mysql-slow.log</div><div>
<div>long_query_time = 5</div><div>log-queries-not-using-indexes</div></div><div><br></div><div>El archivo lo podés analizar con:</div><div>mysqldumpslow -t 10 /usr/local/mysql/data/mysql-slow.log</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<br></div><div>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.</div><div><br></div><div>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:</div>
<div>SELECT notas.*,usuarios.username FROM notas JOIN usuarios ON <a href="http://usuarios.id">usuarios.id</a>=notas.id_usuario LIMIT 10</div><div>Para analizarla, ejecutaríamos:</div><div>EXPLAIN SELECT notas.*,usuarios.username FROM notas JOIN usuarios ON <a href="http://usuarios.id">usuarios.id</a>=notas.id_usuario LIMIT 10</div>
<div><br>El resultado es algo así (en el mail se va a ver feo, miralo por pantalla o copialo-pegalo y acomodá las lineas):</div><div><div><font class="Apple-style-span" face="'courier new', monospace">+----+-------------+-------------+--------+---------------+---------+---------+----------------------------------------------+------+-------+</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">+----+-------------+-------------+--------+---------------+---------+---------+----------------------------------------------+------+-------+</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| 1 | SIMPLE | comentarios | ALL | NULL | NULL | NULL | NULL | 192 | |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| 1 | SIMPLE | usuarios | eq_ref | PRIMARY | PRIMARY | 4 | hispabodas_hispabodas.comentarios.id_usuario | 1 | |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">+----+-------------+-------------+--------+---------------+---------+---------+----------------------------------------------+------+-------+</font></div>
</div><div>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.</div>
<div><br></div><div>Con todos estos datos podés analizar un poco mejor la consulta, saber cómo la ve el motor y optimizarla.</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>Yo no usaría conexiones persistentes, por todo lo que te dijo Leo.</div><div><br></div><div>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).</div>
<div><br></div><div>Estoy a punto de escribir algo un poco más detallado sobre esto. Cuando tenga tiempo lo haré.</div><div><br></div><div>Cualquier cosa avisá y reportá resultados.</div><div><br></div><div>Saludos, Matias.</div>
<div><br></div><div><br><div class="gmail_quote">El 31 de agosto de 2010 18:17, Leonardo Tadei - Pegasus Tech Supply <span dir="ltr"><<a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hola Gonzalo,<br>
<br>
El mar, 31-08-2010 a las 06:34 -0300, Rama Gonzalo escribió:<br>
<div class="im">> Hola, tengo una DB con algo mas de 140 consultas y 10 inserciones<br>
> aprox. por segundo (usuarios diferentes) y tengo problemas en el<br>
> rendimientos, desde ya que se puede deber a mil cosas, pero quisiera<br>
> saber si las conexiones persistentes me pueden ayudar a mejorar un poco<br>
> o complicaría más la cosa.<br>
> Y en que casos en conveniente y en cuales no.<br>
<br>
</div> Casi nunca convienen las conexiones persistentes, y sobre todo, no son<br>
aplicables cuando los usuarios de la DB son distintos.<br>
Si implementás conexiones persistentes, tenés que tener mucho, pero<br>
mucho cuidado de cerrarlas correctamente, porque si no se te cae el<br>
server por demasiadas conexiones abiertas.<br>
<br>
Para este caso, tal vez te convenga más implementar un sistema de<br>
caché, para que las 140 consultas bajen a la misma cantidad que tenés de<br>
inserciones.<br>
<br>
Después, el paso que sigue son tablas en RAM, y bajarlas a disco cada<br>
tanto, y de ahí pasás a clusterizar el almacenamiento o pasarte a DB no<br>
relacionales, que según dicen pero yo no probé, tienen muy buen<br>
rendimiento bajo estos escenarios, aunque en el camino perdés la<br>
consistencia automática de los almacenamientos.<br>
<br>
> Muchas gracias.<br>
<br>
Por nada!<br>
<div class="im"><br>
--<br>
<br>
Leonardo Tadei<br>
<a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a><br>
<a href="http://blog.pegasusnet.com.ar" target="_blank">http://blog.pegasusnet.com.ar</a><br>
Firma pública: <a href="http://www.pegasusnet.com.ar/LeonardoTadei-public.key" target="_blank">http://www.pegasusnet.com.ar/LeonardoTadei-public.key</a><br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Php-avanzado mailing list<br>
<a href="mailto:Php-avanzado@pato2.fi.mdp.edu.ar">Php-avanzado@pato2.fi.mdp.edu.ar</a><br>
<a href="http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado" target="_blank">http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Matias Fernando Gea<br><a href="mailto:matigea@gmail.com">matigea@gmail.com</a><br><a href="http://www.mfgea.com.ar">http://www.mfgea.com.ar</a><br>
</div>