2010/2/9 Cristiam Castillo <[email protected]> > Hola a todos, > > Ha llegado el momento de escalar nuestra aplicación. Necesitamos enviar > miles de emails en menos tiempo, tener un site más estable y más rápido > y mejorar los tiempos de respuesta y la cantidad de solicitudes por > segundo. > > Por ello, suelto este hilo: ¿han escalado sus aplicaciones web? ¿qué > arquitectura recomiendan? >
me dicen q es mala educacion responder una pregunta con otra pero alla vamos q entiendes por escalar ? si por lo q veo, estas entendiendo mejorar tiempos de respuesta, eso no es, eso pasa mas por una labor de profiling de tu codigo, de interaccion de tu codigo con tu arquitectura (servidor web, aceleradores web, base de datos, etc) para lo cual puedes recurrir a profiling y verificar los puntos donde puedes obtener mejoras si realizas cambios (generacion contenido estatico, aplicar ESI si tu web front-end lo permite, si el lenguaje q usas permite el uso de threading o multiprocessing para ejecutar procesos en paralelo, etc) escalar es q puedas manejar mayor carga (mas visitas, mas consultas, mas users) sin q la performance del site o sites q manejas se vea degradada. Eso va mas alla de mejorar tus tiempos de respuesta, claro, eso ayuda en esta parte pero al final lo q buscas con escalar q si tuvieras 10, 100, 1000 consultas por segundo a tu sitio la respuesta del site a las consultas sea la misma, no se degrade. > 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. > prueba primero a colocar un servidor de cache a tu servidor web, squid en modo web acelerator o mi favorito, varnishd. puedes incluso jugar con ESI para q segmentos de una pagina sean cacheados (esas partes q varian bien poco en ellas) balanceadores de carga tienes para escojer desde hardware hasta software especifico (pound) o modulos en servidores web (apache, nginx o lighttpd) q hacen esa labor. > 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. > q tambien tienes q analizar se podria convertir en el talon de aquiles de una arquitectura donde el update de informacion es bastante, los tiempos de refresco a los esclavos. usas MyISAM ? InnoDB ? esta optimizada la bbdd para aprovechar el server o esta con los settings by default ? has probado los forks de MySQL de Percona y OurDelta ? > Tambien se divide los archivos "assets"(imágenes, textos fijos, audios y > videos) generalmente la idea es q estos sean servidos desde otro servidor, un CDN q puede ser tuyo o contratado para el proposito. > y las BDs de datos de las de estadísticas, se des-normaliza y se > aplica caché con memcached. > tu aplicacion no usara magicamente memcached, ni tampoco dejara de usar los counts o los group by q tienes en tu codigo por desnormalizar tu bbdd, esto va de la mano de tu codigo en este caso. otro detalle mas, una vez q tienes varios servidores en tu arquitectura, como reaccionas ante la falla en un punto critico ? servidores de contingencia, alguien dijo clusters ? activo-pasivo ? activo-activo (heartbeat, redhat cluster suite) ? monitoreo de servidores (monit, nagios, god) finalmente dado q estas en web, quizas tambien te interese revisar cambiar apache (q nadie aprovecha en realidad pq la mayoria lo configura en prefork, cortesia q php no es thread-safe) por nginx o lighttpd (este ultimo aun mi preferido en ese caso), tux web accelerator si usas, rhel, fedora o centos, o incluso darle una chance mas al viejo apache pero en modo thread, minimizar la cantidad de modulos usados en el mismo (si usas php en tu aplicacion, cambiar a otro servidor web o a apache con thread engine, implica cambiar la configuracion de php para q se use fastcgi en este caso) en fin, suerte en tu aventura, ya nos diras como te va -- Yonsy Solis, aka Black Hand
_______________________________________________ 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
