>I want to be sure I understand your advice. You are saying that when ASP finishes processing a page, any VFP COM object that was created during the processing of that page is released (i.e., destroyed), and any VFP tables that were opened by that COM object are closed. Does this also means that when going from page to page, one derives no caching benefits that we usually anticipate from VFP when using it in a LAN environment?
Well, NT performs some caching of its own and the VFP runtime stays loaded, but the actual tables do close. It's the equivalent of you sitting at the command prompt opening and using a table, closing it and then reopening it.
As far as comparison - I don't provide that. The reason is that a) it should be pretty obvious, and b) you really need to check it out for yourself, because it will vary with the types of applications you write.
>If this is so, then would you anticipate getting better performance from the VFP ODBC driver rather than using a VFP COM object with ASP? Doesn't the ODBC driver and its memory cache have a life that is independent of the Connection Object that is used to communicate with the driver? Is the latest release of the driver from spring 1999 still single threaded?
The VFP ODBC driver is pretty much worthless for anything but small apps. It's single threaded and will not process two queries simultaneously. It'll open any table though and leave it open, so yes you get caching there. The VFP ODBC driver will not become multi-threaded from what I've heard. A future OleDb provider may likely be.
>I still feel like I need bottom-line info pertaining to performance and scalability when choosing between FOXISAPI vs ASP/COM(SP3) vs ODBC. Just rules of thumb, so to speak. Could you point me to the pages in your book or web site that provide this info?
I've done informal testing only and then only ASP vs. Web Connection but the numbers should be roughly the same for FoxISAPI since the technology is similar.
Web Connection's server access overhead was between 2-3 times faster than ASP COM access. This can be attributed to the COM objects loading/unloading. This counts only for making a simple COM call that spits out some simple HTML result to provide content. If you use MTS objects ASP fares slightly better but it's still 2 times slower than WC.
As you add data access against large tables into the mix the performance differences become much more pronounced because WC caches its environment including any open tables (unless of course you close them explicitly). The first hit on a WC server is slower than the ASP average, but subsequent hits are much faster. If you now start adding lots of COM calls in an ASP page into the mix (as opposed to a single method call to generate result data) the overhead gets even worse on the ASP end.
Some requests that accessed data files with 50,000 records and pulled out about 40 of them ran more than 4 times faster in Web Connection than in ASP using hte identical processing code (same classes etc) when run under light load (1000 requests in 10 minutes). As the load increased performance of ASP in relation to WC decreased steadily and at worst scenarios was up to 8 times slower than Web COnnection. Remember these are identical code bases...
These are informal numbers and I picked worst case scenarios for ASP on purpose - the thing is that WC (and FoxISAPI presumably) have much fewer worst case scenarios to watch out for because the internal VFP caching takes care of many of those issues for you...
Now keep in mind that if you are using ADO for data access these differences are going to work in ASP's favor when you compare side by side with other tools like WC. But also understand that ADO adds its own COM overhead to data access itself. Again in comparison of VFP native data access either against SQL Server using ODBC connections vs. ADO native VFP data access and using the data somehow (either by generating HTML or converting to a usable table) resulted in 2 - 20 times better performance of using VFPs data access natively.
