Dr. Hawkinsv wrote:
>> Phil Davis wrote:
>> > As it stands right now, the engine is single-threaded so there's no
>> > distributing of anything to other cores within a single instance of
>> > your application. As for the future, I can't address that.
>>
>
> My thinking is that the application launches, and then it uses shell
> commands to launch, say, three other instances which will listen on
> three other ports. Initial connections would be round robin-ed (?)
> to the four ports. Crude, but possibly effective.
A lot of load balancing systems use round-robin. It may be crude, but
widely used.
> Richard Gaskin wrote:
>
>> If Mark Wieder would be kind enough to add forking to the Server
>> engine we could pass socket connections to child processes, and
>> build our own NgineX.
>>
>> Mark, got a few minutes to do that? Thanks. :)
>
> In the scenario I see, it wouldn't be on server, but an application:
> revOpenDatabase() is *far* to expensive to call on each instance;
> the port needs to stay open and connected to the db. (~500 ms to
> open vs. ~20ms to tap)
We need to call revOpenDatabase from a CGI because the CGI is being
launched with each request. With an always-on socket server it should
need to connect to the DB only once when it boots, which would ideally
happen when the system boots so it's always up and running and ready to
handle requests at any time.
Conjecture about parallelism aside, half a second seems a very long time
just to open a DB connection. It may be worthwhile submitting a bug
report so that can be reviewed.
Then again, the broad variance you've noted (as short as 20ms) suggests
there may be something else at play. What could cause such a dramatic
difference in the execution of a relatively simple connection? What
other processes are running on that server?
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
