[Top][All Lists]
[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
- Re: [Gnumed-devel] choice of web frameworks, (continued)
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/12
- Re: [Gnumed-devel] choice of web frameworks, lkcl, 2010/07/12
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/12
- Re: [Gnumed-devel] choice of web frameworks, lkcl, 2010/07/12
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/13
- Re: [Gnumed-devel] choice of web frameworks, Karsten Hilbert, 2010/07/13
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/13
- Re: [Gnumed-devel] choice of web frameworks,
Karsten Hilbert <=
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/13
- Re: [Gnumed-devel] choice of web frameworks, Karsten Hilbert, 2010/07/13
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/13
- Re: [Gnumed-devel] choice of web frameworks, lkcl, 2010/07/14
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/15
- Re: [Gnumed-devel] choice of web frameworks, lkcl, 2010/07/15
- Re: [Gnumed-devel] choice of web frameworks, Elizabeth Dodd, 2010/07/15
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/15
- Re: [Gnumed-devel] choice of web frameworks, Karsten Hilbert, 2010/07/15
- Re: [Gnumed-devel] choice of web frameworks, Sebastian Hilbert, 2010/07/15