(My two cents)
In this problem, there are several layers,
already. So, i don't think that adding an extra javascript layer (i don't discuss the possibilities of Pas2JS) will help to better understand the problem (nb: i'm still only using simple CGI technlology).
AFAIK, a CGI - fast or not - application is a console application that creates or recreates a web session (depending of its DOS\Bash PATH_INFO parameters); it basically creates or reload an array "$PASCAL_SESSION", and then creates a SQL "child" session of this "parent" web session.
So, already, depending on the database server you are using, there are parameters to manage the parameters of a SQL "child" session a.k.a. a SQL connection a.k.a. a MySQL thread.
❶ About the SQL server (which one do you use? I'm going to assume it's MysQL\MariaDB):
- here, there is an "axis of approach" to the same problem (CGI web server applications being also console applications):
https://forum.lazarus.freepascal.org/index.php/topic,49600.msg359993.html#msg359993.
- there are hints here:
https://dev.mysql.com/doc/refman/5.7/en/gone-away.html (
"...The number of seconds the server waits for activity on a noninteractive connection before closing it...;...On thread startup, the session wait_timeout value is initialized from the global wait_timeout value or from the global interactive_timeout value...").
- ...
❷ concerning fast over single CGI:
Just like you wrote it, i think that i've understood (honestly i didn't read the documentation; and more importantly: I have neither read the Object Pascal code, nor tested it in the same directory as my project) that fast-CGI leaves the CGI program loaded in memory, in a kind of listening mode of the change in value of the PATH_INFO environment variable. If this is the case, I would look first and foremost, at how to raise the execution priority of the
loaded fast-CGI program.
@PascalDragon wrote:
And IIS uses normal CreateProcess functions to load them, so IIS can't do anything special here.
I think this information means that there may be nothing to do on the priority side when
loading fast-CGI-application with IIS (did I understand that right? But what about an already
loaded fast-CGI-application?).
❸ Then, as far as logging is concerned, LCLProc.DebuglnThreadLog is enough, for me, and for now, to understand my CGI application.