gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] choice of web frameworks


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] choice of web frameworks
Date: Tue, 13 Jul 2010 12:11:34 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Jul 13, 2010 at 11:47:03AM +0200, Hilbert, Sebastian wrote:

> > gmPG2 creates connections upon request.
> > 
> > It will pre-open one read-only connection per thread. They
> > are handed out again and again as needed.
> > 
> > It will open a new read-write connection on each write
> > request.
> > 
> That is the missing link I am looking for. A stateful framework should have 
> the ability to alway connect to that GNUmed connection pool (where GNUmed is 
> handing out the connection).

That pool exists inside each imported gmPG2.

> should be possible to get around with a few connections. It depends on how 
> fast a request can be served and the connection freed.

Creating connections is slower than serving the read
requests - in most of GNUmed use cases.

> I wonder how bad performance would be if we were to work with like 50 
> simultaneous connections (like 50 concurrent wxpython clients).

It wouldn't matter at all unless they were all writing to
the same patient at the same time. Other than that - peanuts.

> We are not neccessarly in for the hospital where you need to scale to 
> thousands of clients. We are talking an absolute maximum of 20 clients in a 
> really huge practice.

The place I work we do have 20-something clients. I don't
consider it a huge practice, though.

> > Currently GNUmed uses up to three threads:
> > 
> > - the main one in which the GUI is executed
> > 
> > - one for the database signal listener
> > 
> > - one for the XML-RPC scripting API if so configured
> > 
> > > Since we support more then one fat client (each haaving its own
> > > connection) I guess serving 10 clients (10 connections) should not be a
> > > problem.
> >
> So if we operate 5 client in an office and each thread is active then there 
> are 15 concurrent database connections. Is the connection limit a hard limit 
> of PG or a user defined limit set by GNUmed ?

There is no connection limit unless the user sets one in the
PG configuration.

PG defaults to some number like:

        max_connections = 100                   # (change requires restart)
        # Note:  Increasing max_connections costs ~400 bytes of shared memory 
per 

GNUmed uses exactly as many connections as it needs. Given
the PG default you could run 30 clients full tilt without
needing to change a thing (if the machine is beefed up to
the task).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]