>So, I suppose the response to the customer in this case would be, "You need a server farm.".
Possibly. Another option is to dedicate a server to handle these sort of requests and queue them asynchronously.
This might help, but you will still need at least one additional machine to offload to:
http://www.west-wind.com/presentations/wwAsyncWebRequest/wwAsyncWebRequest.htmYou'll still get the slowness (on another box) but at least your Web Server keeps running...
BTW, heavy duty processing scenarios always a problem for Web applications. You can do this with pure ASP.NET as well, but most other environments are much more forgiving than VFP.
If you're running code manually (ie. not runnin a single huge SQL statement or Report), you can throw some DOEVENTS or maybe a Thread Sleep() into the processing code to give up CPU cycles.
I've had a few applications where I've replaced very complex SQL queries that were killing the CPU with a lot of xBase code to be able to cut CPU usage by strategically placed DOEVENTS calls.
+++ Rick ---
>
>-E-
>
>
>>As long as you compiled your components as an MTDLL you should be Ok. IIS will launch these DLLS on separate threads and simultanneously in MOST cases. Unless you are storing your objects on a Session or Application object in whcih case you are binding component to a specific thread. Don't EVER do that <g>...
>>
>>Also make sure you have ASPCOMPAT enabled. Without that you may see all sorts of funky behavior.
>>
>>The other issue you need to be aware of is that VFP will suck all the CPU out of a machine if it gets busy. So if you're doing heavy duty data acess or tight loop processing in your code VFP may very well nearly take over the CPU of the machine. Other requests would still run but much more slowly.
>>
>>+++ Rick ---
>>
>>>I have an ASP.NET web reporting system that uses a VFP Interop DLL to retrieve data via XML to generate Crystal PDF reports and Excel spreadsheets. The code works in independent sessions using unique session directories and databases created on the fly by SessionID. All this is fine, the reports never get confused and everything is stored in its own subdirectory per asp.net session and gets cleaned up later by a service.
>>>
>>>The problem is this. Say a user starts a session and runs a report that might take 10 minutes. Another user comes along and wants to log in. The session starts just fine and renders the login page, however it needs a VFP object to check the users ID and password. ASP.NET seems to only want to run one VFP object at a time and sits and waits for the 10 minute report in another session to finish before it will release the process and handle the next request, which is to login the new user. The same thing is true even if several users are already logged in and running reports. If some chooses to run a lengthy report when it get the attention of asp.net then everyone else gets delayed until the bigger report is finished.
>>>
>>>This went basically un-noticed for a long time because under normal usage you wouldn't notice the delay while asp.net juggles the requests.
>>>
>>>I want the web application to run Sessions in it's own memory space and only concern itself with running code in the current session regardless of what is happening in another session. Right now aspnet_wp.exe sits and processes one Interop request at a time while all other users have to wait. Can this be done?
