El día 16 de diciembre de 2008 16:04, Juan Alfredo de Martin <[email protected]> escribió: > Muchas gracias a todos, me dan un monton de ideas utiles, calculo un > gran numero de conexiones concurrentes porque tambien seran turnos por > web o moviles y la cantidad de pacientes entonces accediendo va a ser > importante > > El día 16 de diciembre de 2008 15:59, Alvaro Herrera > <[email protected]> escribió: >> Juan Alfredo de Martin escribió: >>> Hola, >>> >>> Tengo que desarrollar una aplicación web que tendra un numero elevado >>> de conexiones concurrentes(10000). Alguien me puede decir cual es el >>> máximo soportado por PostgreSQL?. O que experiencia hay al respecto >> >> Hace no mucho le escribi a otra persona sobre el tema de las conexiones >> concurrentes y los sitios web. Pego abajo lo que ella decía y mi >> respuesta: >> >>> tengo 1000 usuarios conectados al sitio web, haciendo peticiones a la >>> base de datos, pueden varias peticiones ser ejecutadas a través de una >>> misma conexión. >>> El que hace esta labor de administración de conexiones es pgpool o >>> pgbouncer, pero este es un programa que debo instalar por aparte. >>> Existe otra explicación a que 1000 usuarios haciendo peticiones a la base >>> de datos no sean 1000 conexiones concurrentes? >> >> La explicacion es que no hay 1000 usuarios concurrentes. Los usuarios >> humanos leen, piensan, y se demoran en achuntarle al link con el mouse, >> asi que hay tiempos de retardo entre una peticion y la siguiente. Si >> 1000 personas visitando paginas que se demoren 20 segundos en cada una, >> son 50 peticiones (paginas) por segundo. Si cada pagina tiene 2 >> consultas a la BD para desplegarse, son 100 consultas a la BD por >> segundo. Si el servidor se demora 0.01 segundos en responderte cada >> peticion, tienes 1 segundo de trabajo por segundo; en otras palabras ese >> servidor puede atender "1000 usuarios concurrentes". >> >> El tema de max_connections es que cada conexion es un proceso. Cada >> proceso usa memoria. Mientras mas memoria tienes desperdiciada en >> procesos, menos se puede usar para cache, shared_buffers, etc. Si >> tienes 1000 procesos se ocupan como 3 GB sólo en ese gasto >> administrativo, y en un server de 4 GB te queda apenas 1 GB para el >> resto de las cosas. Si tienes 100 procesos usas sólo 300 MB en eso, y >> quedan otros 3.7 GB para uso de cache, con lo cual el rendimiento es >> mucho mejor. Incluso puede ser buena idea reducirlos a 10 o 20 >> procesos para reducir el gasto inútil de memoria. >> >> >> -- >> Alvaro Herrera Valdivia, Chile ICBM: S 39º 48' 55.3", W 73º 15' 24.7" >> "XML!" Exclaimed C++. "What are you doing here? You're not a programming >> language." >> "Tell that to the people who use me," said XML. >> > -- > TIP 7: no olvides aumentar la configuración del "free space map" >
No se con qué tecnología bas a desarrollar la aplicación/web. ¿Pero no has considerado impelmentar tecnología de cache para reducir las llamadas a base de datos y mejorar los tiempos de respuesta? -- TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
