Re[4]: how to break out of FCGX_Accept_r - multi-threaded fastcgi performance

Hello Emil,

EAE> That seems likely, implementations for other web servers might not have the
EAE> same problem...

I actually saw it on lighttpd web server, too. Single-threaded fcgi apps
work fine while multi-threaded fcgi apps have big latency. So, it
could also be on the libfastcgi part.

EAE> 1) Under unix I run them as daemons, managed by rc.d scripts. For windows I
EAE> run them as nt services.

There are two things that I see missing compared with the mod_fastcgi
approach:

a. mod_fastcgi manages the processes and start new processes if some
   processes died or stopped responding. This is good for high
   availability.
b. fcgi apps can "recycle" themselves (quit after serving a number of
   requests and let mod_fastcgi start some new ones) This is good for
   dealing with memory leaks.

EAE> 3) I've only used mod_fastcgi2.

This is what I talked about but I haven't got a chance to try it:
http://fastcgi.coremail.cn/

Jack

EAE> ----- Original Message ----- 
EAE> From: "Jack" <[email protected]>
EAE> To: "Emil A Eklund" <[email protected]>
EAE> Cc: <fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org>
EAE> Sent: Friday, November 18, 2005 15:00
EAE> Subject: Re[2]: [FASTCGI] how to break out of FCGX_Accept_r - multi-threaded
EAE> fastcgi performance


>> Hello Emil,
>>
>> Thanks for the reply. This more or less confirms the issue. But maybe
>> it's a mod_fastcgi issue because external servers do not have that
>> problem.
>>
>> Now I have three questions:
>>
>> 1. For external servers, how to you manage running/restarting the
>> servers? mod_fastcgi does that nicely. I suppose you write your
>> own scripts to monitor the external servers?
>>
>> 2. External servers would use sockets. How does it affect performance
>> compared with domain socket?
>>
>> 3. has anyone had good experience for multi-threaded fcgi apps
>> with the other Apache fastcgi module, what was it called again -
>> something like lib_fcgi?
>>
>> -- 
>> Best regards,
>> Jack
>>
>> Friday, November 18, 2005, 8:28:35 AM, you wrote:
>>
>> EAE> Yeah, I get excellent performance from multi threaded FastCGI 
>> applicationms,
>> EAE> when running as an External Server. Hav had quite a few problems with
>> EAE> dynamic servers and multithreading, even when limiting the number of
>> servers
>> EAE> to one.
>>
>> EAE> /Emil
>>
>> EAE> ----- Original Message ----- 
>> EAE> From: "Jack" <[email protected]>
>> EAE> To: <fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org>
>> EAE> Sent: Friday, November 18, 2005 13:55
>> EAE> Subject: [FASTCGI] how to break out of FCGX_Accept_r - multi-threaded
>> EAE> fastcgi performance
>>
>>
>>>> Hello,
>>>>
>>>> If you need to recycle the fastcgi processes, using a counter
>>>> is much easier than a timer. I know this doesn't really answer
>>>> Andrej's question :)
>>>>
>>>> I have another question though. I'm glad to see lots of replies
>>>> to the question. I suppose many people are using multi-threaded
>>>> fastcgi servers because FCGX_Accept_r() is the thread-save version
>>>> of FCGX_Accept(). Or, do most people just use FCGX_Accept_r()
>>>> in single-threaded fastcgi servers?
>>>>
>>>> Anyway, I have a question for the multi-threaded fastcgi developers.
>>>> I tested the multi-threaded sample and experienced very poor
>>>> performance. Each request takes about 3 seconds. I sent an email
>>>> to the list but didn't get any replies. I thought no one was using
>>>> multi-threading :) I also read another earlier post mentioning the
>>>> same 3-second issue with Apache2 + mod_fastcgi. I used lighttpd but
>>>> the symptoms were very similar. So, my question is, are you, the
>>>> multi-threading users, getting good performance? Even with the
>>>> sample that comes with fastcgi? Could there be something that I did
>>>> wrong?
>>>>
>>>> -- 
>>>> Best regards,
>>>> Jack

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/