In reading this thread I see a number of issues here. 1. The time it takes Active4D to handle and dispatch a request. 2. The time it takes Active4D to return a response. 3. The time it takes for the database engine/application logic to handle the response.
Active4D (with 4D's Web Server or NTK) can handle 1 and 2 well. Clayton points out a good example where 3 may take a long time. When using Active4D I like to let the code in my Active4D pages do as much of the work as possible. We need to keep our site up 24/7 if possible. Recompiling and publishing a new structure whenever we need to make "web changes" prevents that. Keeping all of the changes in A4D allows quick site changes. The exception would be this case. On Web Connection and/or OnWebAuthentication are not multi-threaded. But 4D (sort of) is. Active 4D can call 4D methods that can start new processes. One solution might be to have Active4D handle the request, start a job which runs a 4D process on the server (or another client), and immediately return a response. That response contains a reference to the process that is running on the backend. Your backend can track process status in a table or an IP array at the back end. Your returned page will wait a few seconds and send a simple "is my job done" request. The back end will determine if the job is done. If it not it sends a simple try later response. It it is done the results, or a reference to those results, are returned. If you know that your processing will typically take 10 - 20 seconds you can retry less often (less load on a4D). Your retries can be done via a refresh in the page's HEAD or with Javascript (AJAX). These days I'd use the latter. So this is really a case of not how many requests can A4D handle, but what processing capacity can your 4D backend handle. Depending on your expected load you might have a web "client" handling your web requests and a pool of processing clients (or server processes) doing the heavy lifting. -- Brad Perkins Donahue, Clayton L. wrote: >> 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. > > - Clayton > > _______________________________________________ > Active4D-dev mailing list > [email protected] > http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev > Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/ > > _______________________________________________ Active4D-dev mailing list [email protected] http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
