Hey Aaron, 2016-01-04 17:44 GMT+01:00 Aarón Bueno Villares <abv15...@gmail.com>:
> 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. > > 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). > > - > - 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. > > - 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
------------------------------------------------------------------------------
_______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
