Hey,

2016-01-07 0:24 GMT+01:00 Aarón Bueno Villares <abv15...@gmail.com>:

> 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?) ?

>
>>>    - 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.


> 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.
>
> It will send an error in the 50x range (I'm not sure which one though, I
could look it up).

>
>    - 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
------------------------------------------------------------------------------
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to