[Info-vax] How would you load balance excess webserver traffic between multiple OpenVMS servers?

[Jan-Erik Söderholm]

Den 2021-01-11 kl. 17:28, skrev Marc Van Dyck:
> Arne Vajhøj formulated the question :
>> On 1/11/2021 9:45 AM, Marc Van Dyck wrote:
>>> Arne Vajhøj expressed precisely :
>>>> On the web servers you need the application code & data to stay resident
>>>> in memory and reuse threads/processes to process requests as
>>>> starting processes and loading images are expensive. And
>>>> the database connections need to be managed by a connection pool
>>>> as open connection is expensive (note that a connection pool
>>>> also require application code& data resident in memory).
>>>>
>>> Wasn't ACMS made to solve just that problem ? Has one already tried to
>>> implement a web server with ACMS - assuming anyone still knows the
>>> product, that is ?
>>
>> I know little about ACMS, but it is my clear impression that it
>> is way more than a database connection pool.
>>
>> A database connection pool is really a simple concept.
>>
>> Without pool: request processing opens a physical connection
>> to the database, do what it need to do and closes connection.
>>
>> With pool: at startup N connections are made, request processing
>> borrows a connection from the pool use it and return it.
>>
>> There can be some bells and whistles with pool size
>> increasing and decreasing over time depending on demand,
>> the pool making keep alive queries, failover handling etc. -
>> but the basics are very simple.
>>
>> Arne
> 
> My answer was about the whole paragraph, not just the last sentence...
> I.e. also keeping code in memory and re-using existing processes.
> 

No web server can talk to a "database" in its own. You need some
web server process that does the DB "work". Any web server should
support persitant processes so that multiple requests can be serverd
by in-memory processes that already have the database attach open.

We use Python using PYRTE and WASD and get responstimes as viewed
from the browser in the 10's of millisecond. The Python overhead is
also very low due to the fact that the process already have the
Python environment loaded and "compiled".

If it has been calm for the timeout period (configurable, think it
is 5-10 min by default) there is a 0-5 - 1 .0 sec Python startup
delay for a new process to be created.