El día 9 de febrero de 2010 16:17, Cristiam Castillo <[email protected]> escribió:
> Hasta ahora, luego de leer varias horas, siento que la arquitectura > "mejor" utiliza un balanceador de carga (apache mod_load_balancer) que > canaliza la solicitud (http, smpt, etc) a un "cluster" de servidores web. > Además se trabaja con bases de datos MySQL en modo Master - Slave. Cada > webserver podría tener un MySQL "slave" de sólo lectura y la base de > datos Master es donde se escribe. > Tambien se divide los archivos "assets"(imágenes, textos fijos, audios y > videos) y las BDs de datos de las de estadísticas, se des-normaliza y se > aplica caché con memcached. Las estrategias fáciles son: a) Los "assets" definitivamente a un servidor por separado que use un servidor web lo más liviano posible y con el menor footprint de memoria posible para que se puedan atender simultáneamente la mayor cantidad de solicitudes que el hardware permita. A los ya mencionados como lighttpd o nginx puedes darle una mirada a otro menos conocido pero no menos interesante: Cherokee, que es extramadamente modular, con lo que reduce mucho se consumo de memoria, bastante rápido y tiene rutinas que minimizan el tiempo en que un cliente web se queda esperando por recibir respuesta, en la práctica atendiendo a varias solicitudes en simultáneo de manera parecida a como los procesos comparten el CPU. b) Tuning del S.O. del host, que si es Linux hay varias cosas que puedes ajustar a nivel del kernel y de distintas capas para que el rendimiento sea el mayor. Por ejemplo, a nivel de sistemas de archivos quizás no te interesa perder milisegundos actualizando la última hora de acceso de tus archivos estáticos a los que no haces caché. c) Abandona Apache ASAP y pásate a lighttpd, nginx o Cherokee con PHP en modo FastCGI. ¿Usas PHP? No has comentado mucho al respecto, creo que trabajas con Ruby On Rails por la otra lista a la que copias el correo. Las recomendaciones ya no tan fáciles serían: d) Optimiza tu frontend, hay todo un libro bastante corto dedicado a ello que le puede dar una sensación de mejora en la rapidez percibible a los usuarios sin que cambies nada en el backend: http://oreilly.com/catalog/9780596529307 e) Has un uso adecuado del cache, utiliza "etags" y en general no vuelvas a generar dinámicamente ni enviar al cliente algo que no ha cambiado desde la última vez que solicitó al recurso al servidor. f) Utiliza caché en RAM (memcached) para almacenar cualquier cosa que sea más rápido recuperar de la RAM que de la base de datos o volver a generar: resultados de consultas, fragmentos de plantillas que tienen valores calculados pero que cambian muy poco, etc. g) Identifica los actuales cuellos de botella, encuentra formas de eliminarlos, reescribirlos para que sean mas simples o de paralelizar tareas que no sean interdependientes. Ver: Las recomendaciones difíciles son: h) Reescribe completamente tu capa de persistencia de datos para que puedes escalar horizontalmente. Eso significa casi siempre utilizar la técnica de "sharding". Ej. la tabla de usuarios dividida en varias bases de datos sin que un mismo objeto este repetido en dos de ellas. Si quieres implementar un esquema master-slave lo podrías hacer a nivel del "shard", para asegurar la disponibilidad del "shard" por un tema de redundancia. Ver: http://www.slideshare.net/oemebamo/database-sharding-at-netlog-presentation i) Ya que estas ahi te conviene optar por un esquema de llave-valor y ya no utilizar el SQL de manera tradicional. Empresas como Friendfeed y Facebook prefieren utilizar un motor relacional probado como MySQL para soportar un schema de llave-valor, de esa manera, es mas fácil agregar y quitar campos a una entidad, sin tener que hacer ALTER TABLE en todos lados ni tener caidas en el sistema. Ver: A criterio de muchos los motores nuevos de NoSQL como CouchDB, MongoDB, Cassandra, etc, etc son muy interesantes y prometedores pero no están lo suficientemente maduros como para producción. Esto es algo muy relativo pero sin duda los productos no tienen la madurez de MySQL o PostgreSQL ni existe tanta experiencia en como usarlos ni como solucionar los problemas que se presentan con estos programas, que en su mayoría no llegan aún a su versión 1.0 j) Reescribe tu código para que sea asíncrono. Si usas Ruby podrías usar EventMachine http://rubyeventmachine.com/ En conclusión yo te aconsejaría primero "medir" bien cual es el rendimiento actual de todo tu sistema y probar primero las opciones fáciles y alguna de las intermedias bien seleccionadas. Luego mides que tanto haz mejorado y si es suficiente vas ganando tiempo para intentar alguna mejor mas elaborada. Para poder mandar mas mails vas a tener que paralelizar y balancear la carga entre varios servidores SMTP. También deberías usar algo que haga que el código web no se quede esperando la respuesta del servidor SMTP sino que sea un proceso batch el que recoja los mails por enviar y los envie. Algunas ideas que espero que sirvan complementando y reforzando lo que ya han dicho otros. Creo que también ayudaría que nos cuentas cuanto tráfico recibes ahora, con que hardware lo manejas y cuales son tus proyecciones. Suerte, Antonio Antonio _______________________________________________ Lista de correo Linux-plug Temática: Discusión general sobre Linux Peruvian Linux User Group (http://www.linux.org.pe) Participa suscribiéndote y escribiendo a: [email protected] Para darte de alta, de baja o hacer ajustes a tu suscripción visita: http://listas.linux.org.pe/mailman/listinfo/linux-plug IMPORTANTE: Reglas y recomendaciones http://www.linux.org.pe/listas/reglas.php http://www.linux.org.pe/listas/comportamiento.php http://www.linux.org.pe/listas/recomendaciones.php
