[Wt-interest] Understanding Dynamic FastCGI + SharedProcess/DedicatedProcess mode

[Aarón Bueno Villares]

I have lost about three days checking the Wt source code trying to figure
out what kind of risks there could be if I would choose a dynamic FastCGI
deployment for my Wt site, because there is nearly no documentation about
that, and I'm not sure about anything.

My web server is an Apache 2.4.7.

I'll try to sumarize my doubts with the following questions/sentences:

Suppose that I deploy my website as a dynamic FastCGI aplication under
dedicated process mode, with a maximum number of 100 sessions, and after X
days of working, Apache has created 5 instances of the same process (5 Wt
main processes):


- Do I have a maximum of 500 sessions? (100 sessions per main process).
Because each fcgi/Server instance has its own `sessions_` object.

- If the first Wt process created by Apache, launchs an auxiliary
process to manage the sessionId 4 (for example), and another HTTP requests
arrive for the same session, Apache sends that HTTP request to a process of
his choice, so, the HTTP request for the sessionId 4 could be delivered to
a Wt process which didn't create the corresponding session process. How is
managed that? As far as I know after reading the source code, both main
processes will be connected to the same session socket, and I don't know if
that is the expected behaviour. I mean, should I use dedicated process mode
for dynamic FastCGI applications?

About the second point, if the deployment strategy were SharedProcessMode
instead of Dedicated, the question would be very similar, because
everything is about having different Wt process which knows nothing about
the other ones.


So, what approach is safer?

[Koen Deforche]

Hey Aaron,

Post by Aarón Bueno Villares
I have lost about three days checking the Wt source code trying to figure
out what kind of risks there could be if I would choose a dynamic FastCGI
deployment for my Wt site, because there is nearly no documentation about
that, and I'm not sure about anything.
My web server is an Apache 2.4.7.
Suppose that I deploy my website as a dynamic FastCGI aplication under
dedicated process mode, with a maximum number of 100 sessions, and after X
days of working, Apache has created 5 instances of the same process (5 Wt
- Do I have a maximum of 500 sessions? (100 sessions per main
process). Because each fcgi/Server instance has its own `sessions_` object.
Yes. You should thus only use this in combination with a static FastCGI

deployment. There's little benefit in the 'dynamic' nature (which is
probably intended more for single-threaded single-process applications).

Post by Aarón Bueno Villares
-
- If the first Wt process created by Apache, launchs an auxiliary
process to manage the sessionId 4 (for example), and another HTTP requests
arrive for the same session, Apache sends that HTTP request to a process of
his choice, so, the HTTP request for the sessionId 4 could be delivered to
a Wt process which didn't create the corresponding session process. How is
managed that? As far as I know after reading the source code, both main
processes will be connected to the same session socket, and I don't know if
that is the expected behaviour. I mean, should I use dedicated process mode
for dynamic FastCGI applications?
It uses a directory of named pipes to manage sessions. So no matter

through which session-manager process the request arrives, it will end up
in the correct session-process.

Post by Aarón Bueno Villares
- About the second point, if the deployment strategy were
SharedProcessMode instead of Dedicated, the question would be very similar,
because everything is about having different Wt process which knows nothing
about the other ones.
It's implemented in a similar (but slightly different way).
So, what approach is safer?

You should use a FastCGI configuration in which the number of 'FastCGI'
processes is limited.

However, I would strongly advise against using FastCGI at all. It's old,
unmaintained, and limited. It's also the less popular choice in combination
with Wt.

The more efficient (and the more commonly used) option is to use the
wthttpd connector instead of wtfcgi. Some good reasons for that are:
* FastCGI limits your choice to a few web servers, and this choice is
likely to decrease over time as FastCGI is no longer evolving. With httpd
you can deploy behind any reverse proxy, such as Apache, Nginx, HAProxy, ...
* FastCGI configuration is cumbersome, while reverse proxy configurations
are usually straight forward.
* With HTTPD you have support to additional features: namely WebSocket
support and file upload progress.
* With HTTPD you can still choose for dedicated processes are shared
session processes.
* Development with the built-in httpd is much easier, as you can easily use
gdb, valgrind, etc... as with any other application.
* Performance-wise it's the better option too (the builtin-httpd is based
on async I/O throughout), especially if you're considering server-push
which requires connections to stay open over long time periods.

Regards,
koen

[Aarón Bueno Villares]

Ok, thanks. I'll deploy it as a static FastCGI application in dedicated
process mode (as a Wt newbie, I prefer to avoid risks using shared
processes, and I can't deploy it has a standalone server -wthttpd- for
different reasons; although sooner or later I will try to add a reverse
proxy to deploy it that way).

Post by Koen Deforche

Post by Aarón Bueno Villares
- Do I have a maximum of 500 sessions? (100 sessions per main
process). Because each fcgi/Server instance has its own `sessions_` object.
Yes. You should thus only use this in combination with a static FastCGI

deployment. There's little benefit in the 'dynamic' nature (which is
probably intended more for single-threaded single-process applications).

The reason I was originally interested in using the dynamic deployment is
because, at least under Apache, the process manager uses a load balancer to
decide to which dynamic instance send the request. Isn't it an adventage?
Because that could improve performance if, otherwise, the request arrives
to a busy Wt process, isn't it?

I have a last couple of related questions (dynamic FastCGI; dedicated mode):

- If a dedicated Wt process reachs its limits of sessions, and the web
server decides to send a new request to it (corresponding to a new
session), what will happen with that request? Will it be ignore? Will the
web server detect the serving refusal and send it to other dynamic FastCGI
process?, or will it retry after a waiting timeout? or once delivered, the
webserver takes no more responsabilities of it? I want to understand it
because I want to avoid timeouts as mush as possible.


- In case the webserver cares about the refused request and try to serve
it by other means (creating new instances for example), will this happen
after a timeout (because the web server receives no answer for example) or
immediately (because the FastCGI protocol has special messages to inform
about refusal of requests, so, the web server can try an inmediate
solution)?


Best regards,
Peregring.

[Koen Deforche]

Hey,

Post by Aarón Bueno Villares
Ok, thanks. I'll deploy it as a static FastCGI application in dedicated
process mode (as a Wt newbie, I prefer to avoid risks using shared
processes, and I can't deploy it has a standalone server -wthttpd- for
different reasons; although sooner or later I will try to add a reverse
proxy to deploy it that way).

But can't your web server already act as a reverse proxy (in the same way
as it acts as a FastCGI host?) ?

Post by Aarón Bueno Villares

Post by Koen Deforche

Post by Aarón Bueno Villares
- Do I have a maximum of 500 sessions? (100 sessions per main
process). Because each fcgi/Server instance has its own `sessions_` object.
Yes. You should thus only use this in combination with a static FastCGI

deployment. There's little benefit in the 'dynamic' nature (which is
probably intended more for single-threaded single-process applications).

The reason I was originally interested in using the dynamic deployment is
because, at least under Apache, the process manager uses a load balancer to
decide to which dynamic instance send the request. Isn't it an adventage?
Because that could improve performance if, otherwise, the request arrives
to a busy Wt process, isn't it?

Since you're using dedicated processes anyway, there won't be such a thing
as a busy Wt process?
A single FastCGI process can handle multiple incoming requests
simultaneously, and uses a thread pool to do so.

Post by Aarón Bueno Villares
- If a dedicated Wt process reachs its limits of sessions, and the web
server decides to send a new request to it (corresponding to a new
session), what will happen with that request? Will it be ignore? Will the
web server detect the serving refusal and send it to other dynamic FastCGI
process?, or will it retry after a waiting timeout? or once delivered, the
webserver takes no more responsabilities of it? I want to understand it
because I want to avoid timeouts as mush as possible.
It will send an error in the 50x range (I'm not sure which one though, I

could look it up).

Post by Aarón Bueno Villares
- In case the webserver cares about the refused request and try to
serve it by other means (creating new instances for example), will this
happen after a timeout (because the web server receives no answer for
example) or immediately (because the FastCGI protocol has special messages
to inform about refusal of requests, so, the web server can try an
inmediate solution)?
FastCGI indeed has some timeouts which it uses to detect that a

down-stream process is not misbehaving (for example not responding to a
request, or not generating a response fast enough). How those are
configured are entirely dependent on the server (module) implementation
though as this is not specified in the FastCGI protocol.

Regards,
koen