Re: Prestart Jobs for speeding up TCP/IP servers

On 10/26/21 9:18 AM, Patrik Schindler wrote:

Do I get this correct? You had a socket listener running (as
PJ?), and dynamically spawn workers?

I did something like that for my TCP servers. Although I had a user
configurable number of workers pre-spawned.

Like the Apache httpd does.

Essentially, yes. Different mechanism, same effect.

I didn't use PJ jobs ... I just submitted regular batch jobs to
QUSRNOMAX.

I understand. But submitting these would impose a penalty in terms of
CPU spikes and time until the batch job is ready to run, and can
continue servicing requests from the socket connection. As said, I
want to make my idea run as efficient as possible on my 150. :-)

No real CPU spike, I don't think. The job submits and waits until the monitor job hands it work to do.

The data queue is used to hand the socket descriptor from the
monitor job to the worker job.

The socket descriptor is AFAIR just a number. Why not pass it as a
parameter? Or is "entry arrived in the *DTAQ" the signal for the
already running worker to, well, start work?

Ah, Sorry, I misremembered.

The data queue is used for the individual server jobs to send their internal job id's to the monitor job. The monitor job uses the job id to pass to the givedescriptor api.

The server job calls take descriptor which waits for the monitor job to
send the socket information to it.

In a nutshell...

The monitor job starts and launches n number of server jobs.
Each server job sends it's internal job id to a data queue
The server job then sits on takedescriptor until it's handed work to do

The monitor job gets a connection
It gets the next server jobs internal job id from the data queue
It calls the givedescriptor api with the server job's internal job id
It then spawns new server job to take the place of the server job that
was just handed a connection

david