[uylug-varios] Thunderbird discontinuado ?

[Luis Pablo Pérez]

2012/7/29 Luis Pablo Pérez <kylroy at gmail.com>:
> 2012/7/29 Eduardo Trápani <etrapani at unesco.org.uy>:
>>> Maildir es _mucho_ mas eficiente y
>>> mas rapido, tanto para buscar como para guardar cosas.
>>
>> Estaba pensando, qué es lo más lindo de esto.  Hackear, ¿no?  Así que hice un pequeño programita (va abajo de todo) para comparar la parte de buscar cosas en maildir.  Un mensaje cualquiera lo copio diez mil veces con nombres diferentes en una carpeta y lo concateno diez mil veces en un solo archivo en otra carpeta:
>>
>> original.eml -> mbox/mbx (concatenado)
>> original.eml -> maildir/xyz000 ... maildir/xyz999
>>
>> Y después hago un grep de algo que sé que no voy a encontrar, buscando la respuesta que tendría si la cadena a buscar estuviera en el mensaje 1001.
>>
>> Resultados con el comando time:
>>
>> $ time egrep -r "esto seguro que no lo encuentro" maildir
>>
>> real    0m0.178s
>> user    0m0.020s
>> sys     0m0.092s
>>
>> $ time egrep "esto seguro que no lo encuentro" mbox/mbx
>>
>> real    0m0.006s
>> user    0m0.000s
>> sys     0m0.004s
>>
>> ¿Será que maildir es más rápido para buscar?  ;) Los ejecuté dos veces cada uno, para poder alimentar los caché que estuvieran en juego.  Mi máquina no es gran cosa, sus resultados van a ser mucho mejores, pero importa la comparación relativa. Para los curiosos, si hago egrep ... maildir/* el resultado es mucho peor.
>>
>> En realidad es lógico.  Maildir *necesita* abrir y cerrar *cada* archivo para buscar.  Eso tiene un costo.  Ese costo pierde relatividad con el acceso a IO (aunque también es lógico que estén más dispersos en Maildir, que haya más saltos innecesarios por slack, etc.)  Mi suposición es que con archivos más grandes es probable que converjan.  Pero lo que es cierto es que no se puede pretender que sea más eficiente:
>>
>> 1. abrir archivo, leerlo todo, cerrarlo
>>
>> que:
>>
>> 2. abrir archivo 1, leerlo todo, cerrarlo, abrir archivo 2, leerlo todo cerrarlo.
>>
>> Cuanto más uno se acerca a lo que efectivamente pasa a nivel de kernel y filesystem más uno se da cuenta de que simplemente imposible que la búsqueda sea más rápida.  A menos que me esté perdiendo algo, ojalá, porque es lo que me gusta de la lista.  Por ahora me animo a decir que maildir es siempre *más lento* (o *mucho más lento según el filesystem de abajo) que mbox a la hora de buscar.
>>
>> Va el programita por si alguien quiere hacer las pruebas en su propio equipo.
>
> La pregunta es: el problema que intenta resolver maildir es
> performance o escalabilidad ?
>
> Si en lugar de 1 proceso tenes 100 ? y si ahora tu empresa es muy
> famosa y tenes que dar el servicio para 500mil usuarios ?
> Probablemente tengas que colocar esos archivos en algun tipo de
> storage compartido para poder balancear la carga entre varios
> servidores.
>
> Que pasa si tenes un folder compartido, el mismo folder, que es
> utilizado por 500 usuarios ? y 2000 usuarios ?
>
> SI tenes 500k usuarios vas a tener varios servidores recibiendo correo
> y grabando en los folders y varios (quizas diferentes) atendiendo a
> los usuarios leyendo esos folders.
>
> Volviendo a mi mensaje anterior: depende del problema que queres resolver.

Ah, si me olvidaba... como cada mensaje corresponde a un archivo y los
filesystems se portan muy mal con varias decenas de miles de archivos
y las cosas no caminan cuando tenes cientos de miles de correos en un
folder. Si ese es el problema a resolver maildir no va a funcionar
sobre un filesystem que no soporte feliz y contento cientos de miles
de archivos en un directorio.

>
>>
>> $ bash
>> $ ARCHIVO="/tmp/original.eml"
>> $ mkdir /tmp/mbox
>> $ mkdir /tmp/maildir
>> $ for i in {1..10000}; do cat $ARCHIVO >> /tmp/mbox/mbx; a=$(tempfile --directory /tmp/maildir/); cp $ARCHIVO $a; echo $i; done
>> $ time egrep "esto seguro que no lo encuentro" mbox/mbx
>> $ time egrep -r "esto seguro que no lo encuentro" maildir
>>
>> Eduardo.
>> _______________________________________________
>> Uylug-varios mailing list
>> Uylug-varios at listas.uylug.org.uy
>> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy