Skip site navigation (1) Skip section navigation (2)

Re: Conexiones Concurrentes

From: "Damian Culotta" <damianculotta(at)gmail(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Conexiones Concurrentes
Date: 2008-12-16 18:08:59
Message-ID: 8b9e07370812161008w796ea165tac21021b60c40df8@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
El día 16 de diciembre de 2008 16:04, Juan Alfredo de Martin
<666lawyer(at)gmail(dot)com> 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
> <alvherre(at)alvh(dot)no-ip(dot)org> 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?

In response to

pgsql-es-ayuda by date

Next:From: Raul Andres DuqueDate: 2008-12-16 18:32:25
Subject: Re: Conexiones Concurrentes
Previous:From: Juan Alfredo de MartinDate: 2008-12-16 18:04:15
Subject: Re: Conexiones Concurrentes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group