Re: Multi-threaded Fastcgi Performance is Very Poort. But Why?

"Emil A Eklund" <[email protected]>
Newsgroups gmane.comp.web.fastcgi.devel
Message-ID <[email protected]>
Seems quite unlikely that is's a general problem with fastcgi itself.

I have several multi threaded applications using fastcgi in production, and 
performance is excellent, both under windows and unix.

However I have experienced quite a few problems when using multi threaded 
applications with the fastcgi process handler.
I'd advice you to try implementing it as an external server instead, if 
multi threading is desirable.


/Emil A Eklund

----- Original Message ----- 
From: "Jack" <[email protected]>
To: <fastcgi-developers-xGejAJT2w6yOE5Ap4OspEtHuzzzSOjJt@public.gmane.org>
Sent: Friday, November 04, 2005 03:54
Subject: [FASTCGI] Multi-threaded Fastcgi Performance is Very Poort. But 
Why?


> Hello ,
>
> I read it from this email in the archive that multi-thread fastcgi
> apps perform poorly.
> http://www.fastcgi.com/archives/fastcgi-developers/2005-March/003662.html
>
> In order to verify this, I also tried the threaded sample that comes with
> fastcgi. It happens to me, too, that each request takes more than 3 
> seconds
> while single threaded app is very fast (I didn't time it but very fast.)
> I didn't even use ab to test it. Instead, I just have one single request
> each time by refreshing IE window.
>
> I thought maybe it was the mutex code. Then I commented out all mutex
> code (for accept() and for accessing variables.) But the performance
> didn't seem to improve at all.
>
> I wonder why this is the case?
>
> -- 
> Best regards,
> Jack
>
>


--------------------------------------------------------------------------------


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

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.