Hi all,

wc.dll is limited to 32 COM servers.

The doc mentions no such limitation for .NET webConnectionModule.dll (WC 7.2); however, when testing serverCount = 42, 37 COM objects loaded and administration.wc answered unable to retrieve a COM server.

Is webConnectionModule.dll :: serverCount limited?

The problem is that it takes too long to load the instances. There's a 10 second timeout and it takes longer than that to load the last instances and that's why it's failing. I can probably fix that but the problem then remains that server startup will take more than 10 seconds where no requests are getting processed which is unacceptable in most scenarios.

It's a bad idea to run this many instances - heck it's a bad idea to run 20 even. You don't have the CPU to gain any benefit from this except in really rare situations.

If I remember correctly the .NET versions (both .NET module and .NET Core handler) don't have any limits on number of instances, but both will fail when the timeout occurs. I'm adjusting the timeout to be sliding scale (ie. the more instances the longer the timeout) and that did make it work for me to load 40 instances, but it took forever before the server could process requests and then seemed really slow due to the resource usage.

+++ Rick ---

Hi Rick,

Thanks for digging into that…

Our customer asks us about the limits that our application can reach, as you can find machines with up to 128 cores / 256 threads, we are just testing before answering.

I would suggest a timeout per server loading rather than a timeout for loading all servers; this way if a server chokes you can log it and continue with other instances. Also, if this timeout could be a setting in web.config that'd be great to accommodate for all sorts of loading sequences and server speeds.

Could it be possible to serve user requests with COM servers already loaded while loading the rest?

Hi Rick,

Any follow-up on my recent questions?

TIA

The timeouts are per server loading - the issue is when 40 of them are loading simultaneously some of them are loading very slow, and they all have to load before the pool becomes available (can't access the collection before they are all there) - the error occurs if any of them fail to load.

IAC, I'm not changing the way this works. This has too much potential to cause problems if changed at this point. The change I made with a longer timeout that's on a sliding scale should help getting more servers to load.

+++ Rick ---

timeouts per server loading

is it the same as AppConfiguration.Timeout?

server loading simultaneously

I've always seen them load in sequence… is there a setting for that?

40 of them are loading, some of them are loading very slow

I our case, each server loads in about 3 sec.

timeout that's on a sliding scale

Is this feature already existing or to be released?

timeouts per server loading

No the server load timeout is hard coded. It's per server instance and it's 5 seconds, plus an adjustor for the number of instances loading.

I've always seen them load in sequence… is there a setting for that?

No, but it's a relatively new feature that was added recently. It improves load time significantly, but just as before it requires that all servers get loaded before any can be accessed.

I our case, each server loads in about 3 sec.
Is this feature already existing or to be released?

If they don't load sequentially I think you will find that they are not all loading at the same speed depending on the simultaneous load.

It helps a lot to remove any startup code from the server OnInit and move that into the server OnLoad which is now delayed until the first hit comes in. This optimizes instantiation quickly, and delays any 'real' processing or server configuration until the first hit is initiated on the server instance.

This is also 'newish' in v7+ (or maybe late 6ish) when that change was made.

This new feature that uses incremental timeout based on # of instances is unreleased. It'll be in 7.40 which should be out next week if all goes well.

I'll dump it into WebConnectionExperimental.zip so you can try it out.

+++ Rick ---

Thanks Rick for these details.

I’ll sure take a look at this new feature.

We can’t move much FoxinCloud code to .onload(); need to review this in details

You'll want to try get code out of OnInit(). The problem with OnInit() even beyond the timing issue is that you can't capture errors in the FoxPro INIT off of which the OnInit() is running. So if something fails there, you can't get a useful error message as you can't intercept the exception and return it. Instead you get some generic COM instantiation error instead. It's very difficult to debug if something goes wrong.

Using OnLoad() on the other hand is now part of a COM method call, which can set an error message and return more useful information about what goes wrong. It also won't hang all instances as an OnInit() failure (or timeout) would.

+++ Rick ---

Thanks Rick for these advices.

We catch errors during server.init() and log them using oServer.LogRequest().