Rendimiento y tecnicas de estimacion de respuesta

Estimar el renidimiento de una consulta

El factor más importante para hacer un sistema rápido es su diseño básico. Ademas, es necesario conocer los procesos que cumple el sistema y cuáles son sus cuellos de botella. En la mayoría de casos los cuellos de botella nacen de los siguientes factores:

• Búsqueda en Disco. El disco necesita cierto tiempo para encontrar un paquete de datos. Con discos modernos, el tiempo medio para esto es usualmente menor a 10ms, así que en teoría se pueden hacer 100 búsquedas por segundo. Este tiempo mejora lentamente con los discos nuevos y es muy difícil optimizarlo para una sola tabla. La manera de optimizar el tiempo de búsqueda es distribuir los datos dentro de más de un disco.
• Lectura y escritura en disco. Cuando el disco se encuentra en la posición correcta, necesitamos leer los datos. Los discos modernos transfieren al menos 10-20MB/s. Esto es mucho más fácil de optimizar que las búsquedas, puesto que podemos leer en paralelo desde múltiples discos.
• Ciclos de CPU. Cuando tenemos datos en la memoria principal, necesitamos procesarlos para obtener algún resultado. Tener tablas pequeñas en comparación con la cantidad de memoria es el factor mas común de limitación. Pero con tablas pequeñas, la rapidez no es usualmente el problema.
• Ancho de banda de Memoria. Cuando el CPU necesita más datos de los que puede almacenar en la cache de la CPU, el ancho principal de la memoria se convierte en un cuello de botella. Es poco común en la mayoría de casos, pero debe tenerse en cuenta.

In most cases, you can estimate the performance by counting disk seeks. For small tables, you can usually find a row in one disk seek (because the index is probably cached). For bigger tables, you can estimate that, using B-tree indexes, you need this many seeks to find a row: log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1.

In MySQL, an index block is usually 1024 bytes and the data pointer is usually 4 bytes. For a 500,000-row table with an index length of 3 bytes (medium integer), the formula indicates log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 seeks.

This index would require storage of about 500,000 * 7 * 3/2 = 5.2MB (assuming a typical index buffer fill ratio of 2/3), so you probably have much of the index in memory and so need only one or two calls to read data to find the row.

For writes, however, you need four seek requests (as above) to find where to place the new index and normally two seeks to update the index and write the row.

El paquete de pruebas de rendimiento (benchmarks) de MySQL

Esta sección debería contener una descripción técnica del paquete de pruebas de rendimiento de MySQL (así como del crash-me), pero esa descripción aún no ha sido escrita. Sin embargo, puede hacerse una buena idea de cómo hacer pruebas de rendimiento viendo el código y los resultados dentro del directorio sql-bench en el código fuente de la distribución de MySQL.

La finalidad de este paquete de pruebas de rendimiento es visualizar qué operaciones se realizan bien y cuáles lo hacen pobremente en cada implementación de SQL.

Estas pruebas de rendimiento no son multi hilo, así que miden el tiempo mínimo para las operaciones realizadas. Se planea agregar en un futuro pruebas multi hilo al paquete.

Para usar el paquete, deben satisfacerse los siguientes requisitos:

• El paquete de pruebas de rendimiento se proporciona con el código fuente de la distribución de MySQL. También puede descargar una distribución liberada de http://dev.mysql.com/downloads/, o usar nuestro repositorio de código fuente(ver Sección 2.8.3, “Instalar desde el árbol de código fuente de desarrollo”).
• Los scripts de las pruebas de rendimiento están escritos en Perl y usan el módulo de Perl DBI para acceder a los servidores de bases de datos, así que DBI debe estar instalado. También es necesario el controlador DBI específico para cada servidor al que se quiere realizar las pruebas. Por ejemplo, para probar MySQL, PostgreSQL, y DB2, debe tener los módulos DBD::mysql, DBD::Pg, and DBD::DB2 instalados. Ver Sección 2.13, “Notas sobre la instalación de Perl”.

Una vez obtenido el código fuente de la distribución de MySQL, el paquete de pruebas de rendimiento se encuentra en el directorio sql-bench. Para ejecutar las pruebas de rendimiento, compílese MySQL, váyase al directorio sql-bench y ejecútese el script run-all-tests:

shell> cd sql-bench
shell> perl run-all-tests --server=nombre_servidor

nombre_servidor debe ser uno de los servidores soportados. Para obtener la lista completa de opciones y servidores soportados, invóquese el comando:

shell> perl run-all-tests --help

El script crash-me también está situado dentro del directorio sql-bench. crash-me intenta determinar qué características soporta una base de datos y cuáles son sus capacidades y limitaciones. Esto lo consigue ejecutando consultas. Determina por ejemplo:

• Cuáles tipos de columnas se soportan
• Cuántos índicies se soportan
• Qué funciones se soportan
• Qué tamaño puede alcanzar una consulta
• Que tamaño puede alcanzar una columna VARCHAR


  Usar pruebas de rendimiento (benchmarks) propios
  
  Decididamente debería realizar pruebas de rendimiento sobre su aplicación y su base de datos para determinar dónde se encuentran los cuellos de botella. Eliminando un cuello de botella (o reemplazándolo con un módulo“tonto”) puede fácilmente identificar el siguiente cuello de botella. Aunque el rendimiento global de su aplicación sea aceptable, debería al menos hacer un plan para cada cuello de botella, y decidir cómo eliminarlo si algún día realmente necesita un rendimiento extra.
  
  
  Para ejemplos de programas de pruebas de rendimiento portables, mire el paquete de pruebas de rendimiento MySQL. Ver Sección 7.1.4, “El paquete de pruebas de rendimiento (benchmarks) de MySQL”. Puede tomar cualquier programa de este paquete y modificarlo en base a sus necesidades. Así puede probar diferentes soluciones para su problema y probar cuál realmente es más rápida para usted.
  
  
  Otro paquete de pruebas de rendimiento es Open Source Database Benchmark, disponible enhttp://osdb.sourceforge.net/.
  
  
  Es muy común que un problema ocurra sólo cuando el sistema está bajo mucha carga. Muchos de nuestros clientes nos contactan cuando tienen un sistema (probado) en producción y encuentran problemas de carga. En la mayoría de casos, los problemas de rendimiento se deben a cuestiones relacionadas con el diseño básico de la base de datos (por ejemplo, lecturas completas de las tablas no son buenas bajo alta carga) o problemas con el sistema operativo o las bibliotecas. En la mayoría de casos, esos problemas se solucionarían mucho más fácilmente si los sistemas no estuvieran en producción.
  
  
  Para evitar este tipo de problemas, es conveniente hacer pruebas de rendimiento a las aplicaciones enteras bajo la mayor carga de trabajo posible. Para ello, puede utilizarse Super Smack, disponible enhttp://jeremy.zawodny.com/mysql/super-smack/. Como su nombre indica, puede poner de rodillas a un sistema, así que asegúrese de usarlo sólo en sistemas de desarrollo.
  
Mas informacion en http://dev.mysql.com/doc/refman/5.0/es/mysql-optimization.html