Re: [Gnumed-devel] choice of web frameworks

[Sebastian Hilbert]

Am Dienstag 13 Juli 2010, 10:40:37 schrieb Karsten Hilbert:
> On Tue, Jul 13, 2010 at 08:30:06AM +0200, Hilbert, Sebastian wrote:
> > > merging this with SimpleJSONRPCServer.py, and adding in a persistent
> > > psycopg connection into the "client", this would be ready to use _now_.
> > > 
> > > but, you would only be able to use about 2 clients because of the pool
> > > limiting on the gmPG2 code.
> > 
> > I have to find out what that limit actually means. If I got that right it
> > means this that for each client we would need to open one connection. All
> > calls to the database would then however be pooled through the gmPG
> > pooling of that client or do we still have to open one connection per
> > request ?
> 
> 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). I kind of understand that the wxpython 
application is stateful and normal webapps/frameworks are stateless and would 
have to create a new connection for every request. In our scenario however it 
should be possible to get around with a few connections. It depends on how 
fast a request can be served and the connection freed.

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

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. And if you need more then this then you better install a 
few virtual machines, serving 20 clients each.

> 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 ?
 
> Not at all.
> 
> > That still does not solve the problem that clients could open up threads
> > and bring down the server, doesn't it ? Is there some sort of keepalive
> > mechanism.
> 
> PostgreSQL 9.0 eventually built keepalive into libpq.
> 
I wonder if this helps since we need to poll the availability of the client 
which does not have a direct connection through libpg. The web app would need 
some code to pretend someone is active (e.g. a dummy request every 5 minutes 
or so) If that request does not come through (webapp or browser closed) then 
the session/thread would be killed.

This topic is interesting since it not only shows that the web was never 
designed to have applications but also that generations of programmers have 
modeled their needs around the web instead of modeling the web around their 
needs.

I am really looking forward to seeing some proof of concept code that it is 
indeed possible to hook the normally stateless web to the stateful serverside.

Sebastian