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.
By the way, could you give me more details about you "a new module
design from scratch"? I'm very interesting about that.
Thanks again!
Fang
在 08-2-14，Gabriel Barazer<[EMAIL PROTECTED]> 写道：
> Hi,
>
> While the mod_fcgid module hasn't received the complete input data,
> nothing is sent to the FastCGI application (which isn't even aware of
> such a request). And even with the mod_fcgid 2.2, there is still a bug
> somewhere and apache leaks memory till death (I'm sure of it, I'm the
> one who reported the bug and proposed a solution).
>
> It is at the moment conceptually not possible to stream the data
> directly to a fastcgi application (mod_fcgid buffers the entire input
> data first, then tries to send it to a connected socket or spawn a new
> instance). The only way to make this work would be to contact the socket
> first, then buffering input data and sending it to the application by
> chunks. This is not really easy with the current design, and it is why
> the "buffer-to-tmp-file" workaround is used (although this workaround
> doesn't work properly).
>
> The only way to not make Apache dying, is to ... use CGI with the
> application used for uploading (this is easy to do for only a specific
> script with a .htaccess handler rule). This way you don't kill the
> performance gained from FastCGI for your other scripts, but you disable
> it for the upload script (which doesn't gain any performance from
> FastCGI anyway).
>
> And if you are wondering why this design has been chosen at the first
> time by the author, this is because for *very small* input data (<64k),
> buffering in the server module allows the FastCGI application to process
> requests very efficiently, without waiting for input data and have too
> many busy sockets. Although this is a good idea, the protocol spec and
> white paper doesn't state any need for buffering before the FastCGI
> application (the application has to do it itself). This way applications
> can make full implementations of some data input handling such as
> on-the-fly mime decoding, stream filtering, RFC1867, etc. which cannot
> be handled by mod_fcgid (by design!).
>
> Anyway, I'm thinking of building a new module design from scratch, and
> maybe even coding it (I'm far better at designing than coding such
> projects, though). The idea would not be to take over the mod_fcgid
> module, but rather improving it and make it more conform to standards.
> This would be a great step to widespread its use (what we all want).
>
> I can provide some tools, hardware, to help test and develop that (Linux
> only, not the Windows versions, sorry).
>
> Cheers,
>
> Gabriel
>
> PS: Could you please use only english in your messages? ;-). It's not my
> native language either, but so practical!
>
> On 02/13/2008 7:41:28 AM +0100, "Ang FAN" <[EMAIL PROTECTED]> wrote:
> > sorry, there are a wrong,
> >
> > while(FCGX_Accept(&request.in,&request.out,&request.err,&request.envp)
> >
> > shoulde be：
> >
> > while(FCGX_Accept_r(&request) == 0)
> >
> > 在 08-2-13，Ang FAN<[EMAIL PROTECTED]> 写道：
> >> Hi,
> >> Thank you,but I do that as you say,the memory still keep growing.
> >>
> >> 你好，用中文吧，我按你说的改了，但是内存(apache)还是不停的长，我的程序是这样写的，你看看有什么问题吗？
> >>
> >> int main (void)
> >> {
> >> streambuf * cin_streambuf = cin.rdbuf();
> >> streambuf * cout_streambuf = cout.rdbuf();
> >> streambuf * cerr_streambuf = cerr.rdbuf();
> >>
> >> FCGX_Request request;
> >> FCGX_Init();
> >> FCGX_InitRequest(&request, 0, 0);
> >>
> >> DWORD dwPrePrcoess = 0;
> >>
> >>
> >> while(FCGX_Accept(&request.in,&request.out,&request.err,&request.envp)
> >> == 0)
> >> {
> >>
> >> fcgi_streambuf cin_fcgi_streambuf(request.in);
> >> fcgi_streambuf cout_fcgi_streambuf(request.out);
> >> fcgi_streambuf cerr_fcgi_streambuf(request.err);
> >> #if HAVE_IOSTREAM_WITHASSIGN_STREAMBUF
> >> cin = &cin_fcgi_streambuf;
> >> cout = &cout_fcgi_streambuf;
> >> cerr = &cerr_fcgi_streambuf;
> >> #else
> >> cin.rdbuf(&cin_fcgi_streambuf);
> >> cout.rdbuf(&cout_fcgi_streambuf);
> >> cerr.rdbuf(&cerr_fcgi_streambuf);
> >> #endif
> >> ResultState nResult = HandleRequest(
> >> &request,paramData,strErrcode);
> >>
> >> cout << "Content-type: text/html\r\n\r\n";
> >> if(strErrcode.IsEmpty())
> >> cout << ResultStateText[nResult];
> >> else
> >> cout << CStringA(strErrcode);
> >>
> >> FCGX_Free(&request,TRUE);
> >> }
> >>
> >> #if HAVE_IOSTREAM_WITHASSIGN_STREAMBUF
> >> cin = cin_streambuf;
> >> cout = cout_streambuf;
> >> cerr = cerr_streambuf;
> >> #else
> >> cin.rdbuf(cin_streambuf);
> >> cout.rdbuf(cout_streambuf);
> >> cerr.rdbuf(cerr_streambuf);
> >> #endif
> >> return 0;
> >> }
> >>
> >> 在 08-2-13，潘庆峰<[EMAIL PROTECTED]> 写道：
> >>> 1. upgrade your mod_fcgid to 2.2
> >>> 2. mod_fcgid 2.2 support a new configuration "MaxRequestInMem" (default
> >>> 64k), every http request longer than 64k will swap to tmp file
> >>>
> >>>
> >>>
> >>>
> >>> 在2008-02-13，"Ang FAN" <[EMAIL PROTECTED]> 写道：
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Ang FAN <[EMAIL PROTECTED]>
> >>> Date: 2008-2-13 11:49
> >>> Subject: Re: confirm
> >>> 1fdecc4c927c4c9e3e26a2a2bc779e5cc2c36c12
> >>> To: [EMAIL PROTECTED]
> >>>
> >>>
> >>> Hi,
> >>> I used fcgid as a file uploader server modul(window 2003 server),but
> >>> if the files are big, it will take the apache memory grow up until the
> >>> apache server crash, why?
> >>>
> >>> thanks!
> >>>
> >>> -------------------------------------------------------------------------
> >>> 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
> >>>
> >>>
> >>>
> >>> ________________________________
> >>> 网 易 有 道 英 汉 电 子 词 典 获 2 0 0 7 年 " 电 脑 报 " 免 费 软 件 最 佳 功 能 奖
> >>> -------------------------------------------------------------------------
> >>> 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
> >>>
> >>>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> -------------------------------------------------------------------------
> >> 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
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
