Hi Joel,

>foxisapi and the asp.net isapi or asp isapi are pretty much the same. Some might argue that there's overhead in carrying around all the objects of Asp/asp.net, but, I would argue that any performance tweaks will go into the asp.net isapi since it's the flagship product(and probably none to foxisapi!). I don't see how you can get better in the fox web world than a dll isapi client(be it asp,asp.net,or foxisapi) talking to a vfp mtdll server as far as performance. In general, any kind of dll is preferable to a standard exe in MT environments for both clients and servers.

That's oversimplifying quite a bit...

Raw ISAPI is ALOT more low level than either ASP or ASP.NET. And in my performance tests it's quite obvious that ASP.NET with COM objects is significantly slower than classic ASP and with good reason: For ASP.NET to make calls to COM components it has to cross the managed to unmanaged code boundaries several times, which is very expensive.

The other thing to remember is that it depends on what you are doing. If you have a single call made by your connector interface like FoxISAPI, Web Connection, AFP etc. or even something like ActiveVFP (which is nothing more than a connector interface using ASP/ASP.NET as the connector) do then you're talking about a single COM hit per request which in the greater scheme of request overhead is a minimal percentage of call overhead (compared to say database acccess). There's no doubt that MTDLLs are many times faster in pure performance numbers that EXE servers - if you were to run a tight loop tests it would be an order of magnitude faster most likely. But the issue is that in a single call this is a fraction of a millisecond for either and compared of running into the ASP or ASP.NET codebase this single call is minmal. Most Fox Web Requests even if they don't do anything more than return a 'hello world' string tend to run around 1-2 millisecond minimum so adding the overhead of a 100th of a millisecond to that is not really going to have much impact on performance.

Things change though if you build a chatty application. Say an ASP or ASP.NET application that uses FoxPro business objects. In that scenario you're making MANY COM object calls to properties and methods in a single request and at that point the overhead becomes much more significant. And the difference between ASP and ASP.NET also becomes much more pronounced as every COM call in .NET crosses the managed code boundary.

I don't think COM calls in ASP.NET will ever have hte perf of classic ASP which is much more low level and wired in all native code unless the .NET CLR comes up with a different way of dealing with COM interfaces in .NET that doesn't involve the expensive context switches and parameter marshalling that is .NET COM interop.

Even though there's much more overhead in the amount of code that runs in ASP.NET native .NET actually scales better because the platform doesn't have to deal with COM and context switches and uses optimized threading configurations that rely on a true multi-threaded environment to provide simultaneous execution. This is why a pure ASP.NET application will easily outperform (in terms of pure framework overhead - this can obviously be affected by bad application design) the same ASP+COM solution or even an all ASP script solution.

I have one reference application (a Web Store implementation) that's implemented as a Web Connection app, a VFP COM wrapper for use in ASP/ASP.NET via MTDLL and also as a native ASP.NET app. The ASP.NET app can manage roughly twice as many requests as the nearest FoxPro solution even though the .NET implementation includes a lot more indirection in the architecture. The Fox solutions are all within a fairly close field as most of the overhead in the app is actually in the Fox code with the Web Connection and ASP+COM solutions almost even in performance. ASP.NET + COM brings up the slowest in that test being about 20 percent slower than the other Fox solutions.


+++ Rick ---