Livecode <=> SQL?
Dr. Hawkins
dochawk at gmail.com
Sat May 23 10:44:19 EDT 2015
On Fri, May 22, 2015 at 6:13 PM, Pierre Sahores <sc at sahores-conseil.com>
wrote:
>>
>> Oh, I see what you mean. At the moment, I'm taking the approach of
>> using a persistent server app, as the time to open a postgres database
>> is significant, and could happen every couple or few seconds for each
>> client.
>
> Should’t be at all. PostgreSQL works in a stateless mode. As long as each
connection to PostgreSQL is :
Maybe it's livecode then :)
I think the last timing figures I had were a little under 100ms for
revOpenDatabase() on localhost (a three or four year old quad-core i5 iMac)
and around 250ms across town, with complex revDataFromQuery() (many
insert/updates followed by a single query) taking something like a third as
long
e.g.,
put the milliseconds into strt
put revDataFromQuery(,,5,dcmd) into theData
put the milliseconds-strt into stp
ck "elapsed: " & stp
(ck is a simple data writing handler)
>
> 1.- opened (by the client, the LC server or the persistant server)
> 2.- processed (the request)
> 3.- closed as soon as the expected data are returned
>
> PostgreSQL will be able to respond very smoothly to thousands of
différent client requests peer second (lost more than Apache can provide
it…).
Apache as a bottleneck?
:)
>
> On the other hand, if each connection is not closed as soon as the job is
done, the main PostgreSQL controller will
>become less and less responsive because the unneeded still opened
connections in its RAM array.
Right now, what I'm writing is a persistent application running on the
server, to which the remote client opens a socket and then writes to. On
initial open, licensing is verified for the session, and some setup is
done. Once initialized and authenticated, client uses write to socket to
send it a command (inserts & updates & a query) with the changed data, and
continues on. When the command is done, the server will write to the
socket, and the client will make local updates.
An http solution would be blocking, which would be bad in this
context--these updates are written while the user is working (it actually
waits until 2 seconds after the last keystroke), but any perceivable delay
would be bad.
The server can close the postgres connection when the socket closes.
Also, I'm thinking that I may be able to drop the query--it's purpose is to
find data updated by other users in nearly real time. Instead, with the
socket staying open, the server could push data to every client using that
table (not conceivably more than a handful), which would mean significantly
less transactions (currently, client is checking every couple of seconds
for updates)
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
More information about the use-livecode
mailing list