From this kb article, I understand that several IIS applications (sites), holding separate .net handlers (each site holds a private bin/webconnectionmodule.dll), even if served by the same application pool, can't share COM server instances.

They have to run separate, dedicated COM servers instance ; eg. with 10 sites and 2 COM instances per site, 20 COM instances must be running.

However, can these COM instances run the same VFP executable?

IOW, could we have (simplified) :

c:\APP\app.exe && regserver'd as 'app.COMserver'

IIS\appPools\myApp

c:\…\wwwroot\site1\ && using 'myApp' IIS app pool
c:\…\wwwroot\site1\bin\webconnectionmodule.dll
c:\…\wwwroot\site1\web.config holds :
   <add key="ComServerProgId" value="app.COMserver" /> 

c:\…\wwwroot\site2\ && using 'myApp' IIS app pool
c:\…\wwwroot\site2\bin\webconnectionmodule.dll
c:\…\wwwroot\site2\web.config holds :
   <add key="ComServerProgId" value="app.COMserver" /> 

etc.

Of course, in this scenario, all sites would share the same wwSession and wwRequestLog tables.

However, can these COM instances run the same VFP executable?

Not quite sure what you mean by that? Do you mean use the same COM Server ProgId? Yes you can. But they will still be separate instances for each site. So if each site runs two instances and you have 3 sites you'll be running 6 instances.

If you're building multi-tenant apps, typically the best approach is to do via a single site (potentially with subfolders for each sub-site) and then use DNS naming and URL routing (site1.mysite.com, site2.mysite.com etc. or even completely different domain names mapped to the same site bindings) to re-route to the appropriate handlers in VFP or handle the tenant initialization based on the Url (if all are running the same code). If you need separate assets like templates images etc. you can use subfolders that map each site and re-route the base paths to access them from within the app.

This is never easy... but it can be done with some tweaking.

+++ Rick ---

Hi Rick,

You've got it right!

My scenario is : x clients using the same application (both site and exe) in isolated execution contexts.

I plan to setup:

• x application pools (one per client site)
• x IIS sites pointing to the same physical directory
• 1 exe

Each client will run its own w3wp, webconnectionmodule.dll, and y COM instances based on the exe.

This way, updating the site directory and/or the exe will update all clients simultaneously.

Right.

Separate Web Sites and App Pools

If you use separate Web Sites and Application Pools you will end up with separate COM instances of the same COM EXE.

Note if you are sharing the same COM ProgId/Exe and use completely separate installs but a shared COM server, you will have to tweak the start up path, wwServer::cAppStartPath and wwServer::cAppIniFile in the server OnInit() so that everything points to your actual Web site's app base folder. This is to ensure that paths translate properly for some things like reading the configuration, writing logs etc.

Doesn't sound like you're planning on doing that, but you rather plan on using a single folder for all separate instances but important to point that out!

Single Web Site with routed Tenants

If you use a single shared Web Site and App Pool and run all tenants through the same app it's possible to share a single set of servers which can be more efficient, but is a lot more tricky to set up.

Thanks for these heads up, I plan to add a column in both wwRequestLog and wwSession to hold the site ID that will come as a sub-domain prefix siteID.xxx.fr.

I will take a close look at wwServer::cAppStartPath and wwServer::cAppIniFile for anything dependent on the siteID (everything related to directory and file locations should be OK).

Ultimately I will setup a set of test sites that I will stress test using parallelFox.

My main concern is how to define the user in dcomcnfg :

• defined user : make sure the total number of instances does not exceed the quota of resources that Windows allocates to each user ; eg. number of file handles
• launching user : make sure we don't face the error not enough memory to complete this operation

launching user : make sure we don't face the error not enough memory to complete this operation

If you're using separate sites and application pools you're not going to have that issue. Also I think your error is coming from the FoxPro server, not from IIS or the worker process - IIS memory usage should never be a problem and the application pool has no impact on the COM servers which run external to it.

For stress testing use something like West Wind WebSurge - no need to create custom tooling in FoxPro.

+++ Rick ---

IIS memory usage should never be a problem

I'll be sure after testing!

For stress testing use something like West Wind WebSurge - no need to create custom tooling in FoxPro.

great suggestion!

I haven't found how to import requests from wwRequestLog … possible?

You wouldn't import from wwRequestLog.

There's a Web Capture tool built-in - so you can walk through a scenario and capture all the Urls.

Alternately the project file is just text of plain Http traces, so you can automate your test scripts if you want so if you want to use wwRequestLog you can do that pretty easily.

+++ Rick ---

Great, thanks Rick