>FOXASPI is a more Fox intensive solution but it may not be the most scalable solution.
Actually that's quite incorrect. FoxISAPI will actually scale much better than ASP with COM. THis because ASP will always reload COM objects on every hit with the associated overhead. If you compare request overhead you'll find that FoxISAPI and other tools are about 2-3 times faster than ASP loading a similar COM object! If you load more than one object into an ASP page it gets much worse.
MTS doesn't help this much, except for some caching it provides but most of that is lost by the fact that an MTS Application/Package runs out of process from the Web server. MTS tightens the gap slightly but not much.
As far as MTS goes you can also run components trhough MTS with FoxISAPI/Web COnnection to gain access to any future sacalability features that MTS might finally provide. Win2k shipping still does not provide any COM load balancing nor does it provide pooling for VFP or VB objects. MTS's current *scalability* features are worthless for Web apps (although there may be other features such as the distributed transaction manager or distributed transaction support that's useful to you).
>It scales by creating a pool of out of process EXE's. This is supposed to be very resource intensive. On the positive side, there are a lot of 3rd party frameworks based on this concept available that streamline the web development process.
Actually it's not. This approach uses memory, but not CPU resources. The MTS/ASP approach is more memory friendly but very CPU unfriendly where FoxISAPI the opposite. ASP has CPU overhead in loading components plus running app code, while a pooled server only has to run app code. You can very easily check this out by createing a do-nothing component that has a method simply returns a string like RETURN "OK". Then stress test that even lightly with 2 requests a second and see what happens to CPU load. Then try the same with FoxISAPI. You'll notice the difference!
Also, components loaded of ASP cannot be controlled in any way - number of instances running and dealing with hung servers etc. No control there. ASP will fire off large number of thread simultaneously and if those threads are doing heavy work you'll kill the machine (it doesn't take much when running a few long VFP SQL statements). With a preloaded server approach you don't have that problem - you start queueing requests or even refusing requests which is much more appropriate in such an environment - instead of killing everyone you ask later people to wait or come back later...
Scalability can be achieved with any Web platform even lowly CGI apps. It's a matter of how soon you outrun single machine resources. Web COnnection, FoxISAPI and I presume some of the other fox server mechanisms will fare much better than ASP in that regard!
>IMO, the advantage to using ASP over the CGI approach is the new VFP MTDLL. This new lightweight runtime can be hosted by MTS which is supposed to be very scalable due to its object brokering scheme. It also offers a lot of other features that are especially useful to applications employing SQL databases. Like tansactions management, connection pooling, security and administration.
MTDLL is not really light weight. 4 megs for the first instance - 600k for any simultaneously loaded ones. Object management and loadbalancing is not available in MTS for NT 4 and also has been dropped in the soon to be shipping version of Win2000. It was also planned only to work in Advanced Server.
>I hear a lot of differing opinons on this, so I really can't say what is best. However, keep in mind that MTS is a key part of MS's DNA framework. A lot of development effort is being invested in it.
This is true, but just because MS says it scales doesn't mean it does. I just ran some interesting Web Connection tests with MS Web Application Stress Tool on new notebook I got. I was running an 8 hour test with 312,000+ hits and 20,000 orders against my Web store - that's well over 1 million hits when spread out over a 24 hour period using that 'non-scalable' platform <s>...
More info on this test can be found at:
http://www.west-wind.com/wwThreads/Default.asp?MsgId=SB30QTT5XI'm not going to tell you FoxISAPI is the best development choice. ASP is fine for most applications, but scalability is one of those things that are a problem when using ASP with COM objects. FoxISAPI is a good tool that lacks support tools to make it work well - too much work to make it do what needs to get done - but that's what third party tools are for to fill that gap.
+++ Rick ---
