Benchmarking de sistema antispam II

Bien, primero de todo darle las gracias a fran por esa clase de Benchmarks tan interesantes que nos ha proporcionado.

Segundo decirle, que ya que hace algo al menos que lo haga bien! Es broma, pero he encontrado algo interesante que podrías probar, y también todos los que queráis :)

En fin… ante los extraños resultados que le ha proporcionado el experimento del post anterior, me he decidido a repetirlo en mi compu, al menos las versiones de 10k y 100k.

A continuación os doy los resultados:

Bien, a primera vista y a última son realmente parecidos a los de fran. El archivo de texto plano apaliza a mysql en 10k, y por contra en 100k, (aqui se ve que el disco duro de fran no debe tener muy buenos tiempos de lectura…) es algo superior, más o menos unos 0.15 segundos.

Así pues la pregunta es, ¿pero como es posible? Ni por asomo debería ser más rápido un fichero que una base de datos, entonces como se puede leer un fichero más rápido que una consulta…

Bueno, primero dejar claro que mysql se portará bien con nosotros si nosotros nos portamos bien con él, es decir, si diseñamos bien nuestra base de datos, él nos dará buenos resultados, y si no, nos dará por culo … (¡ha dicho culo!) perdón por la expresión XD. Veamos a lo que me refiero echando un vistazo a la base de datos de la clase benchmark:

CREATE TABLE IF NOT EXISTS `lista` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`num` varchar(16) NOT NULL,
`timestamp` timestamp NOT NULL …,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=10258450 ;

El caso es que las malas lenguas dicen que se puede multiplicar la velocidad de una consulta varias veces por el simple hecho de usar índices, y más en un caso como éste que siempre hacemos una consulta de dos campos: num y timestamp. ¿Lo probamos?

CREATE TABLE IF NOT EXISTS `lista` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`num` varchar(16) NOT NULL,
`timestamp` timestamp NOT NULL …,
PRIMARY KEY (`id`),
KEY `n` (`num`),
KEY `t` (`timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Y ahora vamos a repetir las pruebas…

Anda…. pues parece que era cierto! XD

 

CONCLUSIÓN

Con el simple hecho de añadir índices a nuestra tabla de mysql hemos logrado reducir a la mitad el tiempo de las consultas y por tanto, texto plano pierde las apuestas!

Ahora solo nos falta que alguien haga el test de los 10 Millones  y podremos sacar conclusiones muchísimo más fiables, ¿quien se apunta?

 

———————– EDITADO:  —————————-

Ya he realizado el último test sobre 10 Millones de entradas y los resultados son muy interesantes:

Como vemos, aún con índices, en este punto el fichero de texto plano se lleva la palma… Sin embargo hay que aclarar algunas cosas:

  1. Hemos conseguido reducir casi 5 veces la velocidad de MySQL por usar indices.
  2. La velocidad en que se tratan los ficheros depende mucho de la CPU y tambíen del disco duro y de la memoria RAM.
  3. Para este experimento se ha tenido que configurar la opción de PHP memory_limit así:  ini_set(“memory_limit”,”10000M”); lo que significa que se ha establecido el límite de memoria que PHP puede usar en 10GB, cosa que es una burrada tremenda, pero que sin ella no era posible tratar con archivos con tantas líneas… de hecho ha habido momentos en que el consumo de RAM por parte de PHP superaba 1 GB, os imagináis la memoria necesaria entonces para procesar un archivo de 100M de líneas? Es totalmente inviable…

Así que pues, dejémonos de archivos de texto plano y usemos bases de datos bien diseñadas y con índices :)

*****11votes
2 Comentarios »  | Categorías:  filadeatras, internet, PHP, programación Tags: ,

2 Responses to Benchmarking de sistema antispam II

  1. franhp says:

    Justo esta mañana se lo he preguntado al DBA de la empresa a ver que se le ocurría y me ha dicho que era un “zokete” por no haberle puesto index :( Este post tendría que haberlo escrito yo esta tarde XDDD

    • hektor says:

      espero que te animes y cuelgues los resultados nuevos, quiero ver si cambia mucho el de las 10M , tu que ya las tienes en la DB 😛

Leave a Reply

Your email address will not be published. Required fields are marked *