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

Hey

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

1) Under unix I run them as daemons, managed by rc.d scripts. For windows I 
run them as nt services.
2) The socket implementation on the unix variant I'm running (FreeBSD) is 
very efficient so I suppose that the difference is negligible.
3) I've only used mod_fastcgi2.

/Emil

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