Thanks for the Thread link, Jim. That was very informative.

The web machine we'll be actually running the queries is a dual P4 with 2 gigs of RAM with RAID 5, very similar in some ways to the machine discussed in the thread.

I am curious about the allusion to the operating system having an ability of taking advantage of the dual processors. Our system is Windows NT 4.0 not Windows 2000. Although it seems that most people felt that it was VFP internally using multiple threads to handle processes.

I was also very interested in the was Ed Raul called thread blocking. It sounded like he was saying that in some instances FoxPro will attempt to use both processors. If it can't get both, it will sit idle until it can. He was also had a reference to a book that people were running multiple SQL commands simultanously to improve performance.

>SNIP
>Dan,
>
>You might well find thread#472486 very interesting.
>
>JimN
>>>
>>>I don't really argue with your alternative.
>>>
>>>But I'm not so sure that "if enough of these requests come in it can slow the web server down to a crawl" is necessarily true. Your problem here is surely I/O-boundedness as opposed to CPU-boundedness. A very good I/O subsystem can do wonders in such a situation.
>>>I had the luxury of working with a StorageWorks (then DEC, now Compaq, I believe) array 6 years ago and it was absolutely MARVELOUS! And imagine what improvements have been made since that time!
>>
>>Actually, we've found that in most cases because FoxPro is such a CPU hog, we were CPU bound not I/O bound. We purchased a box with monster drives and found we were pegging the CPU, so the disk activity was not really the problem.