Re: [Tabularium-devel] Fwd: Algo más usable

[Muammar El K. <mu...@pr...>]

Hola,

2009/12/9 CaStarCo <cas...@gm...>:
> Experimentando con la cache he visto que no da tan buenos resultados
> como sería deseable por las siguientes razones:
>
> · Dado que Tabularium és un programa multiproceso (y no multihilo),
> los procesos están prácticamente incomunicados y no tienen áreas de
> memoria compartida (habría que usar algo más avanzado como MPI... pero
> creo que eso sería complicar demasiado las cosas). Nginx funciona de

No creo que sea necesario, usar MPI ni nada de eso en este momento
pero si tenerlo en mente (ya más abajo dejaré en claro el por qué digo
que hay que mantenerlo en mente). Me parece muy bien que de partida te
estés preocupando por hacer la aplicación lo más rápida y eficiente
posible. Yo te voy a hablar desde el punto de vista de administrador
de sistemas, que es la experiencia que más he tenido recientemente
(doy consultoría a una empresa que tiene un servicio web bastante
demandado). El que un servidor pueda operar correctamente con una
aplicación Web depende de muchas cosas. El hacer llamadas o consultas
inútiles a la base de datos es algo que desmejora mucho el rendimiento
y respuesta de un servidor. El uso de caché también es muy importante,
aunque yo no he podido medir nada al respecto. Pero hay que ver qué se
sacrifica con ello.

Te puedo comentar que un servidor con procesador Intel Quad Core con
un arreglo RAID 5 y 4GB de RAM puede manejar sin problemas al menos
unas 350 conexiones recurrentes y mantener la eficiencia en las
respuestas de manera aceptable. Y te estoy hablando de una página
hecha en PHP que usa como base de datos MySQL. Hay incluso alguna
serie de cálculos propuestos para calcular esto así como también
aplicaciones que te permiten estresar un servidor para tener un
aproximado real del comportamiento en escenarios críticos.

Otros factores pueden gobernar la eficiencia de una aplicación Web.
Supongamos que en el plano ideal, la aplicación está bien hecha en un
90%. Es instalada en un servidor con 12GB de RAM. Pero dicho servidor:

1) No posee una buena configuración de la base de datos.
2) No posee una configuración adecuada del servidor web.
3) Un sistema de archivo no adecuado.

Todos estos factores afectan de manera tal la aplicación que esta es
"perfecta", el performance se va al suelo. Creo que se evitará mucho
este escenario porque tu te estás enfocando en el performance y buen
uso de los recursos. Pero hasta que no se implemente en una situación
como la descrita, no sabremos con seguridad cómo depurar ese problema.

> manera que va rotando los procesos que se encargan de servir las
> páginas a los usuarios (con el algoritmo Round Robin) y puede pasar
> que se tenga que rellenar la caché tantas veces como procesos haya por
> cada usuario (una vez por cada proceso a cada actualización, siempre
> que se el proceso que sirva al usuario X no le haya servido nada
> antes).
>
> Supongo que utilizar una cache en memoria puede ser muy útil para
> ciertas cosas, pero por lo que respecta a almacenar cadenas cortas de
> texto (que es lo que hize en el experimento), acaba siendo una
> complicación innecesaria que prácticamente no aporta una mejora de
> rendimiento sustancial frente al incremento del consumo de memoria.
>

El uso de memoria RAM debe ser consciente. El restar mucha memoria RAM
a un servidor va a traer como consecuencia que la
respuesta de servir páginas se haga mucho menor.

> Para postres, cuando el usuario actualiza sus preferencias puede tener
> problemas ya que si ha rellenado las caches de varis procesos, no las
> actualiza todas (solo la del proceso que estaba funcionando en el
> momento del cambio de preferencias), por lo que a cada actualización o
> cambio de página podrá ver como sus preferencias se alternan entre sus
> preferencias antiguas y las configuradas recientemente. Para
> solucionar eso solo hay una medida: purgar las caches cada cierto
> tiempo... pero es puede eliminar los beneficios de ésta.
>

Sí. Se eliminarían los beneficios del uso del caché.

> Conclusión: eliminaré el sistema de cache (por el momento), por ahora
> ha servido para experimentar, conocer los problemas inherentes a esta
> forma de proceder y poder aplicar lo aprendido a nuevos intentos que
> tengan más interés que el simple sistema de estilos. Otra conclusión
> es que sería interesante estudiar el funcionamiento de sistemas como
> MPI o funciones como mmap que permiten mapear ficheros en memoria para
> usarlos a modo de canales de transmisión de información para comunicar
> procesos. (Como las pipes, pero de acceso aleatorio en vez de ser
> colas)
>

Me parece bien que por los momentos se haya decido dejar de un lado el
tema del caché sino solo para lo necesario. La mayoría de los
proveedores de servicios grandes usan clusters para los servidores web
(yo se que lo sabes, solo lo escribo para que quede en los archivos).
Por ejemplo, en el caso de tabularium sería:

1) Una máquina para la base de datos.
2) Una máquina para contener los libros.
3) Una máquina donde se aloja la página principal.

De esa forma se distribuiría la carga. Lo que no tengo ni idea es de
cómo implementar un cluser Web, tampoco estoy seguro si utilizan el
protocolo MPI u otro, habría que investigarlo.

> Para finalizar, mis disculpas por transformar el desarrollo de
> tabularium en un campo de experimentación y hacer que tarde el doble
> de lo necesario, pero realmente me gustaría conseguir un software que
> pueda comportarse de forma ejemplar ante cargas de trabajo
> descomunales.
>

No, no debes disculparte por eso. Creo que no importa lo rápido que se
haga, pero si lo bien. Calidad...

Saludos,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 127029F1
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-