Hello Clayton,
From: "Donahue, Clayton L." <[email protected]>
A typical web application does a query and shows some results. This
typically takes a second or less.
This is probably a bit of an oversimplification ... web applications are
not simply front-ends for database management, or information browsers.
Ideally, yes - there are some query parameters and a search is done. The
recipe, picture, calendar, etc. is pulled and displayed. This of course
requires that the data be readily available in its "display" form. Look
at travel sites (Orbitz) - they throw up a five or ten second splash
screen and limit your other requests while they are gathering
information.
I mention this because we are in a similar situation - a fairly small
number web requests, each requiring an extensive amount of computation
to provide a result. We *do* cache this end result, so that most of the
time a single query will bring up the desired page. However, data is
shifting and we cannot cache everything ahead of time. Thus, an
un-cached request will come in and consume the server for 10-15 seconds.
Not bad. However, when ten of these requests are suddenly fighting for
resources within the same web process, this causes problems.
In the end, the single 4D language thread is a bottleneck. You can
definitely help out the situation: Using multiple RUNTIME instances was
a good idea. So is using an Apache server as a reverse proxy to serve
static pages. This takes some of the load off of 4D so that it can
concentrate on "application" pages.
I resonate with your response. From the start, I have been designing (and
building) my system with a highly scalable distributed-processing
architecture that lets me offload processor-intensive tasks to any number of
"client" workstations, which serve purely as background processors. Where
possible, a web user's request for compute-intensive work merely schedules a
"task", so the user gets what appears to be a very responsive system.
Meanwhile, the "client" workstations handle the various job queues.
Still, the downside here is that the 4D Processes (launched via 4D's New
Process command) running on any computer will *always* run on a single core,
rather than making use of multiple cores. 4D's weakness is the scalability
of the "business logic" layer (or "application" layer), when that layer is
NOT a client in a traditional client/server architecture.
-Steve Makohin
Oakville, Ontario, Canada
_______________________________________________
Active4D-dev mailing list
[email protected]
http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev
Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
