>What you say would make sense for "old school" scenarios built around "slushing" html rows of data in and out of the browser. It also makes sense if you are marketing against another "kind of" MTDLL architecture.
>
>SCO (Shared Content Objects) places most the load on the client. Almost all the crunching in an SCO environment is client side. Thats the beauty of it!

That's not true at all. All the overhead in 'heavy CPU' load requests almost invariably comes from closed VFP commands like SQL and REPORT FORM etc. that don't give you hooks. If there were hooks it would actually be possible to throttle the CPU with embedded DOEVENT calls.

Whether you have a distributed Fat Client architecture where some logic runs on the client or not, the data access still comes from the server. And that's teh CPU bound operation that is likely to break your app, not generating HTML which is very fast and efficient in VFP. And, don't forget if you are using a distributed architecture you're likely pushing data to the client in some other format like XML which just like XML requires conversion (although it may be internal in some cases).

+++ Rick ---



>
>It would really be nice, since this is a fox board, if those of us that needed help with foxISAPI and VFP MTDLL COMS could benefit from those of us that have the knowledge to get the most of such an architecture, rather than being beat up with war stories related about how something else does a 100 transactions a second. IF that were the case, then maybe such recomendations would have value. But when it's not - why go down that path?
>
>>>Everything will seem fast with 1 web hit, even "file-based" communication. That part can be deceptive. The real test is when you receive many web hits. Yes, the vfp runtime loads up with each vfp server you have running with foxisapi. You should see 3 or 4 VFP exes running in Task Manager under Processes. Foxisapi loads up 3-4 servers by default that wait in the background for web hits.(what happens when you have more than 3-4 hits at one time - they wait!) VFP mtdlls, on the other hand, only load 1 instance of the vfp runtime that is shared among the threads(true multi-threading). All of this processing happens on the server, btw, and there is caching on both client and server. (also none of this is CGI)
>>
>>As usual you bring up a one sided view. The flip side of this scenario is that there's no control in ASP+COM that keeps you from running too many server instances.
>>
>>If you have a busy site that's running CPU intensive tasks ASP will happily give you new threads for your VFP object (up to 25 which I think is the default pool). If you have a site where this actually happens you will quickly find out that this is not a benefit but a major problem. If you run a query or report that takes say 10 seconds to process and you have even 10 of these running side by side for a few rotations in a row, you will see that CPU usage quickly pegs at 100% and throws the machine into a deadlock situation where new incoming request backup the request queue.
>>
>>And don't give me this 'Yeah but most people don't run applications like this' story again. If you're talking about scenarios like this you are talking about people who are actually running into load issues. There are ways around this with ASP just like they are with WWWC because this is a common problem with any kind of Web application. But you need to plan for this and deal with it.
>>
>>Running more instances never gives you better performance - it only gives you potentially better response where short and long requests mix. If you only have long requests or mostly long requests, more instances are a major handicap as they chew the CPU to shreds. More is not always better that's why Web Connection recommends to use 2-3 instances per processor although you can run more. The reality is that if you had the max 32 instances the last of those 32 never would get hit and if they did, they would be preceeded by 31 busy servers and next to useless due to CPU deprivation.
>>
>>More servers can have benefits in certain scenarios. For example if you're running async requests where you have long running requests that post to a message queue for remote processing. In these scenarios requests aren't CPU bound and there more instances are a big help. In this scenario ASP+COM and unlimited instances would work fine. But otherwise - it's a problem.
>>
>>Web Connection deals with this scenario of a fixed server pool with an option to allow requests that are known to run longer to run outside of the fixed pool. So I can optionally set a flag on a long running report and it will fire a new server. This way I get the benefit of a fixed pool and the option of extending the pool in specific sceneraios where a request would otherwise block the pool. It's a simple flag on the query string that does this... this doesn't eliminate the problem (it has the potential to do the same as the scenario I outlined above) but I get to make the architectual choice in the matter whereas with ASP you don't.
>>
>>For typical transactional applications that process mostly quick requests with an occasional long request interspersed you never need and wouldn't even want more than a couple of instances. I've run very heavy processing applications and have run them with as many as 8 instances for testing - in WWWC you can see how the load distributes on the servers because of the optional visual console. Even under the heaviest of load environments the 6th and greater servers in the group never actually got hit before the CPU usage saturated. Again, in some scenarios (remote processing or remote SQL queries where the app just waits for results).
>>
>>(and BTW, this app was processing just over 100 requests a second during peak hours - and almost 150 under load testing)
>>
>>All technology requires that you understand the platform in order to be able to build applications that scale on top of it.
>>
>>
>>+++ Rick ---