HI Anatoli,
>If possible, could you describe what might happen to the web server when several users request such heavy-duty report rendered by VFP MTDLL+ASP application. What could be done to prevent/improve the situation on the server side?
Well, what happens is this:
You load a slow running report and ASP will fire up your COM component and run it on one of the ASP threads. CPU usage will jump as soon as VFP starts into the processing in earnest (long SQL statement etc. - any single commands that run for a long time and you can't break yourself with something like DOEVENTS). Reports too in some cases, but I think the biggest issue is SQL commands. VFP will eat up most of the available CPU.
Now another request comes in (or the same person tries to do it again because he thinks the request failed) and now two requests with heavy processing are chewing at the CPU. Repeat with as many as you need... <g>
If you get enough requests going ASP is eventually going to deadlock as requests are taking to long that they time out and new requests are coming in to back up the incoming request queue.
BTW, this scenario is not specific to ASP+COM - this can happen with anything using VFP as the backend even using the VFP OleDb driver.
Scenarios around this:
1. Make sure users cannot repeat a click. That's the most common problem if you one or two rare requests on your site. Disable the submit button or display a different part of the HTML page once prcessing starts so that the user cna't refresh or click again and fire more requests. Along the same lines its very important to make the user see that something's happening which can be as simple as displaying an animated Gif.
2. Use an external SQL engine. Offloading to SQL Server on another machine (or even the same machine) minimizes this sort of behavior. Offloading obviously releases the CPU load on the local machine and while the request now may tie up an ASP thread (which are limited) this is infinitely less destructive than eating up the CPU. Even if SQL Server is local you get some benefit because SQL Server will not completely take over the CPU as VFP does.
3. Use Asynchronous request processing and offload to a separate machine. This is usually the most reliable and recommended scenario. Instead of processing requests inline in your Web application code run the request in a queued fashion on another machine. This usually involves two things: Some sort of Queing mechanism (MSMQ or a custom queue implementation using tables) and a Process server that can read info out of the queue, process requests and stuff the result back into the queue. You can then either return the request to the user right then (while providing update information) or you can asynchronously provide it to the user by sending an email with the results etc. I wrote up an article many years ago about how to build a VFP based Aysnc Queue manager. It's a Web Connection article but it really applies and can be used with any Web backend using VFP.
http://www.west-wind.com/presentations/wwAsyncWebRequest/wwAsyncWebRequest.htmNote that the problem in these scenarios usually is not the length of time the request takes but hte amount of CPU that's being used. The CPU usage is the killer and in these scenarios it doesn't take much to bring an app to its knees.
Hope this helps,
