|
Muy frecuentemente debemos realizar estimaciones de uso de recursos con la finalidad de establecer recomendaciones o tomar decisiones sobre el despliegue de aplicaciones web y garantizar el funcionamiento óptimo y la escalabilidad de las mismas. De esta manera, muchos establecen ciertas prácticas o recomendaciones generales, pero en ocasiones las que hemos desarrollado a lo largo del tiempo no son suficientes para justificar una decisión respecto a la infraestructura de soporte. En otras ocasiones, el ambiente de ejecución de la aplicación ya es parte de los requerimientos como límites imperativos; por ejemplo, la aplicación debe correr en un equipo con 256MiB de RAM y una tasa de transferencia de X GiBs al año y se debe establecer el límite de clientes de la aplicación. ¿Qué recomiendan en estos casos? Particularmente, quisiera probar con algunas herramientas, como cgroups en Linux, para evaluar el desempeño y escalabilidad de Django en ambientes con memoria limitada. Digamos 64MiB de RAM disponible para el servidor y la aplicación. No quisiera entrar en una discusión sobre qué servidor es más ligero o prácticas para reducir la transferencia de datos o el consumo de memoria. Sino sobre herramientas y procedimientos para respaldar estas recomendaciones. En sus marcas... ;-) Saludos. |
|
Desde hace varios días he estado utilizando Multi-Mechanize en combinación con CGroups y me ha parecido una combinación bastante objetiva y buena. En resumen, con CGroups puedo establecer límites a la memoria y uso de procesador. Creo un Control Group donde voy a ejecutar el servidor web y el de bases de datos usando las utilidades de libcgroup. Luego entonando varios grupos de Usuarios con Multi-Mechanize puedo ver la escalabilidad de la aplicación en las condiciones establecidas por los límites del Control Group. Igualmente puedo ver el rendimiento por separado del servidor web y el de base de datos usando herramientas como AB o HttPerf y pgbench. Saludos. |
|
Estimar los recursos necesarios para una aplicación django es bastante empírico. Pensar en cómo sería escalar desde un servidor web ligero tipo ngix a apache es algo que nunca podrás saber si antes no lo pruebas. Existen demasiados grados de libertad sobre los que operar. Yo intentaría crear una batería de tests de estrés con Selenium o Multi-mechanize, y probaría a cambiar configuraciones de cacheos y número de procesos simultáneos permitidos. A veces la solución más escalable, propiamente dicha, es la que consta de varios servidores, cada uno especializado en alguna parte de la aplicación. Por ejemplo, una configuración típica constaría de un servidor web transaccional y varios servidores cacheados para consultas. En el transaccional, el rendimiento depende mucho de la base de datos y sus conexiones, mientras que en los servidores cacheados se podrían emplear distintas estrategias como ampliar memoria, aumentar procesadores, etc. Estoy de acuerdo contigo en que la única manera de saber el comportamiento de una aplicación bajo ciertas condiciones es probar. Entiendo lo que defines como grados de libertad, y considero que precisamente reducir esos grados de libertad es lo que puede reducir lo empírico de las estimaciones y llevarnos a estimaciones más objetivas. No he probado con Selenium, pero lo tomaré en cuenta dentro de mi batería de herramientas. Gracias!
(28 Nov '11, 12:55)
sebasmagri
|
