On 02/14/2008 2:58:34 AM +0100, "Ang FAN" <[EMAIL PROTECTED]> wrote: > Hi,Gabriel > Thank you very much, and your solutions is properly good. I tried it > several days ago,but CGI application was much slowly than fastcgi > application , I don't know why it work that.and > some times the feedback of the CGI application very slow,it confuse me > for a long time.
CGI applications are obviously slower, and this is why FastCGI has been invented in the first place. But you usually don't really care how much time it takes to start a process for processing input data such as uploading because you don't even notice the delay (uploading data is much longer than just clicking on a link and wait for the application to start, process the request and then reply). Thus using CGI only for processing uploads is not really a problem. You have to specify in a .htaccess rule which script you want to run as CGI and be cautious to not switch all your FastCGI scripts into CGI (I think you will have to separate your upload scripts in a different directory or change the file extension, because using AddHandler directly in the htaccess file will switch all your scripts to CGI and <Location> is forbidden) > By the way, could you give me more details about you "a new module > design from scratch"? I'm very interesting about that. There is some conceptual flaws in the current module because it has been designed for some specific uses (the author's one), then cleaned up to widen its usage. 1- socket handling. FastCGI has been designed to communicate over any socket type (TCP, Unix, named pipes), and such a design requires an abstraction layer capable of dealing with all these types seamlessly. This would allow us to use internal and external FastCGI processes with the same config syntax. 2- About adaptive spawn: The scoring system is a good idea, but currently implemented is a very odd way. We have to use some real world variables to do the tuning. No one really know what is the difference between spawnscore 5 and spawnscore 100. Plus we have to deal with external sockets and all applications that are not spawned directly by the process manager. 3- the critical one: limit the module memory usage to the socket buffers and module internals. We DON'T have to process the input data (there is a FastCGI "filter" role for that!), not even store it anywhere. 4- The logging system has to be more consistent with the apache log system. See how the CGI module does (because it has to deal with a stderr fd as well). 5- the config variables: this is currently very easy to be confused with locally and globally defined environment variables (DefaultInitEnv), and some config directives have very obscure names (SocketPath is one: what socket? the cgid one? maybe the log processing? no. it's the path where fastcgi sockets are stored. Not that obvious when put in the middle of other modules' variables). This is technically the easiest part, but the one which has to be the cleanest too. 6- No one really knows if we have to use FCGIWrapper or Action+SetHandler. There is also some inconsistencies with which application is started as a FastCGI process (you can define a fake/alias one in Action, but not in FCGIWrapper, you can even put the 2 directives together and have a real mess). 7- have a separate "suexec" layer: checking if suexec is enabled, checking for the user and group ID has to be done only once. Please note that these remarks are for improving the FastCGI support in Apache, spreading its use and maybe one day be included in the standard apache distribution (I read somewhere that IIS has started considering this). I am not saying the current module is crap and to not use it, because I use it everyday in production and know its internals very well. But we (FastCGI+Apache users) could do better ;-) Note: I would really appreciate to have comments from the original author(s). Has anyone a little time to revive this project ? Cheers, Gabriel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mod-fcgid-users mailing list Mod-fcgid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
