why will FastCGI not be supported in the Future.
Hi, I'm a little bit puzzled why there are growing Number of Mails telling that the support for FastCGI will disappear in the future. Why is this. I am running multiple sites that are hybrides of apache/php and zope. It's very easy to set up such a config with mod fastcgi and Apache. It works just fine and very stable, even on heavy load. The posibility to Easy integrate Zope in existing apache/php server was one of our main reasons to use Zope. I know there is a way to do just the same with mod_proxy, but mod_proxy does open new connection for every request while fastcgi uses the same connection for all requests. The is no problem on low load. But with growing load, this can become a Problem. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
--On 28. November 2005 13:28:19 +0100 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Hi,
I'm a little bit puzzled why there are growing Number of Mails telling that the support for FastCGI will disappear in the future. Why is this.
I am running multiple sites that are hybrides of apache/php and zope. It's very easy to set up such a config with mod fastcgi and Apache. It works just fine and very stable, even on heavy load.
The posibility to Easy integrate Zope in existing apache/php server was one of our main reasons to use Zope.
This is not the recommended solution (at least not since several years). There are no plans to remove FastCGI but it is no longer recommended and supported. But this reminds me that we could officially deprecated it and remove it safely after two release cycles (Zope 2.11). -aj
On 28 Nov 2005, at 12:28, Gerhard Schmidt wrote:
I know there is a way to do just the same with mod_proxy, but mod_proxy does open new connection for every request while fastcgi uses the same connection for all requests. The is no problem on low load. But with growing load, this can become a Problem.
Well, it's not "a way to do it", it's *the* way. I highly doubt that your assertion about using more connections than just one is a problem, under any circumstance. All very large production sites that I ever dealt with use mod_rewrite/mod_proxy. It simply is not a problem. Or do you have proof? jens
On Mon, Nov 28, 2005 at 12:43:44PM +0000, Jens Vagelpohl wrote:
On 28 Nov 2005, at 12:28, Gerhard Schmidt wrote:
I know there is a way to do just the same with mod_proxy, but mod_proxy does open new connection for every request while fastcgi uses the same connection for all requests. The is no problem on low load. But with growing load, this can become a Problem.
Well, it's not "a way to do it", it's *the* way.
Thats a real good argument. There is no *the* way. Every situation is different and having as mutch possibilities as possible is allways the best way to do it.
I highly doubt that your assertion about using more connections than just one is a problem, under any circumstance. All very large production sites that I ever dealt with use mod_rewrite/mod_proxy. It simply is not a problem. Or do you have proof?
Im runnig a very large site with 40000 users and a peak arround 60 Requests per second. Having to call connect end all the routines that come with it is quite an increased load. Why. FastCGI work perfectly and efficiently. Thats exactly the usecase Fastcgi was developed for. In none of the Postings is an reason why FastCGI ist bad and therefore not supported in the future. Just to say "so it is" is not an Answer. So my question is still there. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
On 28 Nov 2005, at 13:05, Gerhard Schmidt wrote:
On Mon, Nov 28, 2005 at 12:43:44PM +0000, Jens Vagelpohl wrote:
On 28 Nov 2005, at 12:28, Gerhard Schmidt wrote:
I know there is a way to do just the same with mod_proxy, but mod_proxy does open new connection for every request while fastcgi uses the same connection for all requests. The is no problem on low load. But with growing load, this can become a Problem.
Well, it's not "a way to do it", it's *the* way.
Thats a real good argument. There is no *the* way. Every situation is different and having as mutch possibilities as possible is allways the best way to do it.
It's a matter of resources, plain and simple. No one has stepped forward to support it, so it atrophied. If you think it's a great thing to keep, volunteer. jens
On Mon, Nov 28, 2005 at 01:07:49PM +0000, Jens Vagelpohl wrote:
On 28 Nov 2005, at 13:05, Gerhard Schmidt wrote:
On Mon, Nov 28, 2005 at 12:43:44PM +0000, Jens Vagelpohl wrote:
On 28 Nov 2005, at 12:28, Gerhard Schmidt wrote:
I know there is a way to do just the same with mod_proxy, but mod_proxy does open new connection for every request while fastcgi uses the same connection for all requests. The is no problem on low load. But with growing load, this can become a Problem.
Well, it's not "a way to do it", it's *the* way.
Thats a real good argument. There is no *the* way. Every situation is different and having as mutch possibilities as possible is allways the best way to do it.
It's a matter of resources, plain and simple. No one has stepped forward to support it, so it atrophied. If you think it's a great thing to keep, volunteer.
I would if I had the time and the knowlege. But I don't see a Problem with the Code right now. As I said i runs here perfectly smooth. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
On 28 Nov 2005, at 13:25, Gerhard Schmidt wrote:
It's a matter of resources, plain and simple. No one has stepped forward to support it, so it atrophied. If you think it's a great thing to keep, volunteer.
I would if I had the time and the knowlege. But I don't see a Problem with the Code right now. As I said i runs here perfectly smooth.
"It works" and "is supported" are two different things. "Is supported" also means there are people who will come forward and help out when the code breaks or when people ask questions about it. As you have seen yourself, no one does. The answer is (and will remain, unless someone volunteers): Use at your own peril. jens
--On 28. November 2005 13:28:20 +0000 Jens Vagelpohl <jens@dataflake.org> wrote:
On 28 Nov 2005, at 13:25, Gerhard Schmidt wrote:
It's a matter of resources, plain and simple. No one has stepped forward to support it, so it atrophied. If you think it's a great thing to keep, volunteer.
I would if I had the time and the knowlege. But I don't see a Problem with the Code right now. As I said i runs here perfectly smooth.
"It works" and "is supported" are two different things. "Is supported" also means there are people who will come forward and help out when the code breaks or when people ask questions about it. As you have seen yourself, no one does. The answer is (and will remain, unless someone volunteers): Use at your own peril.
I agree. There should be one supported way to achive a goal. In the past we had at least three methods to run Zope (fortunately we kicked PCGI support in the past). My suggestion is to deprecate FCGI officially in the docs and through a deprecation warning and to kick it at some time (not necessarily after two release cycles). So people can still use but they should know that they are using a deprecated feature...objections? -aj
On 28 Nov 2005, at 14:23, Andreas Jung wrote:
I agree. There should be one supported way to achive a goal. In the past we had at least three methods to run Zope (fortunately we kicked PCGI support in the past). My suggestion is to deprecate FCGI officially in the docs and through a deprecation warning and to kick it at some time (not necessarily after two release cycles). So people can still use but they should know that they are using a deprecated feature...objections?
The deprecation warning should point out that mod_rewrite is the common way to achieve this goal and that FastCGI is plain unsupported. jens
On Mon, Nov 28, 2005 at 03:23:04PM +0100, Andreas Jung wrote:
--On 28. November 2005 13:28:20 +0000 Jens Vagelpohl <jens@dataflake.org> wrote:
On 28 Nov 2005, at 13:25, Gerhard Schmidt wrote:
It's a matter of resources, plain and simple. No one has stepped forward to support it, so it atrophied. If you think it's a great thing to keep, volunteer.
I would if I had the time and the knowlege. But I don't see a Problem with the Code right now. As I said i runs here perfectly smooth.
"It works" and "is supported" are two different things. "Is supported" also means there are people who will come forward and help out when the code breaks or when people ask questions about it. As you have seen yourself, no one does. The answer is (and will remain, unless someone volunteers): Use at your own peril.
I agree. There should be one supported way to achive a goal. In the past we had at least three methods to run Zope (fortunately we kicked PCGI support in the past). My suggestion is to deprecate FCGI officially in the docs and through a deprecation warning and to kick it at some time (not necessarily after two release cycles). So people can still use but they should know that they are using a deprecated feature...objections?
Sure I object. Why should perfectly working code be removed. There is no alternativ for heavy loaded sites which need integration of apache and zope. mod_proxy is no alternativ because it raises the load even further. Bye Estartu ------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt@ze.tum.de TU-München | WWW & Online Services | Tel: 089/289-25270 | Fax: 089/289-25257 | PGP-Publickey auf Anfrage
On 28 Nov 2005, at 14:52, Gerhard Schmidt wrote:
Sure I object. Why should perfectly working code be removed. There is no alternativ for heavy loaded sites which need integration of apache and zope. mod_proxy is no alternativ because it raises the load even further.
Sorry, I have to call "Bullshit" on the assertion that mod_proxy raises the load in any horrible way. I have been using Zope for more than 6 years and no one has ever made this claim or provided proof that this is so. jens
--On 28. November 2005 15:52:25 +0100 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Sure I object. Why should perfectly working code be removed. There is no alternativ for heavy loaded sites which need integration of apache and zope. mod_proxy is no alternativ because it raises the load even further.
I've seen lots of heavy loaded Zope sites - I've not seen a single one using FastCGI. Can you give us some number about the FastCGI performance compared to the standard mod_rewrite approach? Let numbers speak....But please read carefully...I wrote about deprecating the module but not about removing it as in my original posting. We want o make clear that FCGI is not supported. You are of course free to use it as long as you need. -aj
On Mon, Nov 28, 2005 at 04:09:31PM +0100, Andreas Jung wrote:
--On 28. November 2005 15:52:25 +0100 Gerhard Schmidt <estartu@ze.tum.de> wrote:
Sure I object. Why should perfectly working code be removed. There is no alternativ for heavy loaded sites which need integration of apache and zope. mod_proxy is no alternativ because it raises the load even further.
I've seen lots of heavy loaded Zope sites - I've not seen a single one using FastCGI. Can you give us some number about the FastCGI performance compared to the standard mod_rewrite approach? Let numbers speak....
I don't have exakt numbers. We started with pcgi and had heavy problems under load. They disapeared with the fastCGI module coming wird zope 2.6 i gues. I ve tried mod_proxy back than but had many problems. I can not test on the Production system as there are 40000 users on the system and we have enougth Problems with Readconflictes and Session problems.
But please read carefully...I wrote about deprecating the module but not about removing it as in my original posting. We want o make clear that FCGI is not supported.
Yes but if its deprecated it can disapear from any new version. And thats an situation i'm not very comfortable with.
You are of course free to use it as long as you need.
I know. I will read me in the FCGIServer and see if I can understand how its work. But my time is Limited. (Running and developing a portal for i 40000 user with 3 Fulltime workers isn't that easy). Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
On Mon, Nov 28, 2005 at 04:29:22PM +0100, Gerhard Schmidt wrote:
I don't have exakt numbers. We started with pcgi and had heavy problems under load. They disapeared with the fastCGI module coming wird zope 2.6 i gues. I ve tried mod_proxy back than but had many problems. I can not test on the Production system as there are 40000 users on the system and we have enougth Problems with Readconflictes and Session problems.
I'm not surprised you had problems with PCGI, it was known to be extremely slow. AFAIK it ran zope in single-threaded mode so concurrency was terrible. It sounds like you have concluded that, because FCGI is faster than PCGI, then FCGI must also be faster than mod_rewrite / mod_proxy. That's just not logical. p.s. If you're having session problems and read conflicts with 2.6, you should strongly consider upgrading to *at least* 2.7.3 and maybe 2.8. Heavy use of sessioning is still not perfect (see Dennis Allison's recent threads), but it is *much* better since 2.7.3. In addition, ReadConflictErrors are greatly reduced since the release of ZODB 3.3, which first shipped with Zope 2.8. -- Paul Winkler http://www.slinkp.com
On Mon, Nov 28, 2005 at 11:06:35AM -0500, Paul Winkler wrote:
On Mon, Nov 28, 2005 at 04:29:22PM +0100, Gerhard Schmidt wrote:
I don't have exakt numbers. We started with pcgi and had heavy problems under load. They disapeared with the fastCGI module coming wird zope 2.6 i gues. I ve tried mod_proxy back than but had many problems. I can not test on the Production system as there are 40000 users on the system and we have enougth Problems with Readconflictes and Session problems.
I'm not surprised you had problems with PCGI, it was known to be extremely slow. AFAIK it ran zope in single-threaded mode so concurrency was terrible.
It sounds like you have concluded that, because FCGI is faster than PCGI, then FCGI must also be faster than mod_rewrite / mod_proxy. That's just not logical.
No, I just described the way we came to fastcgi and that it solved some of the Problems back than. I pretty sure that mod_proxy is much better than pcgi was. But logic tells me that it can't be better than fastcgi. Building a new connection costs time and CPU power and as the this connections have to be build for each request the impact grows with the number of requets.
p.s. If you're having session problems and read conflicts with 2.6, you should strongly consider upgrading to *at least* 2.7.3 and maybe 2.8. Heavy use of sessioning is still not perfect (see Dennis Allison's recent threads), but it is *much* better since 2.7.3. In addition, ReadConflictErrors are greatly reduced since the release of ZODB 3.3, which first shipped with Zope 2.8.
We are running zope 2.7.8 at the moment and working on mirgating to 2.8.x at the moment exaly for this reasons. Bye Estartu ---------------------------------------------------------------------------- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
Gerhard Schmidt wrote:
I pretty sure that mod_proxy is much better than pcgi was. But logic tells me that it can't be better than fastcgi.
Well, you logic is apparently different from everyone elses ;-) I'm with the everyone-else here, so quite whining about FCGI unless you want to maintain it... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
--On 28. November 2005 16:09:31 +0100 Andreas Jung <lists@andreas-jung.com> wrote:
I've seen lots of heavy loaded Zope sites - I've not seen a single one using FastCGI. Can you give us some number about the FastCGI performance compared to the standard mod_rewrite approach? Let numbers speak....But please read carefully...I wrote about deprecating the module but not about removing it as in my original posting. We want o make clear that FCGI is not supported. You are of course free to use it as long as you need.
Effective from Zope 2.9 I marked FCGI as deprecated - both in the documentation and through a deprecation warning in the sources. Please note that it does not mean that the FCGI might go away automatically in the future. This is basically a reminder for people using FCGI that there is a better way (in our opinion) to run Zope under Apache than using FCGI. -aj
+-------[ Andreas Jung ]---------------------- | | Effective from Zope 2.9 I marked FCGI as deprecated - both in the | documentation and through a deprecation warning in the sources. Please note | that it does not mean that the FCGI might go away automatically in the | future. This is basically a reminder for people using FCGI that there is a | better way (in our opinion) to run Zope under Apache than using FCGI. This of course assumes the entire world runs Apache. -- Andrew Milton akm@theinternet.com.au
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Milton wrote:
+-------[ Andreas Jung ]---------------------- | | Effective from Zope 2.9 I marked FCGI as deprecated - both in the | documentation and through a deprecation warning in the sources. Please note | that it does not mean that the FCGI might go away automatically in the | future. This is basically a reminder for people using FCGI that there is a | better way (in our opinion) to run Zope under Apache than using FCGI.
This of course assumes the entire world runs Apache.
How big do you imagine the set is of people running Zope via FastCGI who are *not* running Apache as the front end? Now how big is the intersection of that set with the set of folks who have (and will use) commit access to Zope? The real issue from Andreas' point of view is that *nobody* who helps maintain Zope also knows and uses FastCGI; *he* used to be the person who did know it (per http://www.fastcgi.com/), but no longer. Without such a person or persons, Zope cannot really claim to support FastCGI at all. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkFtB+gerLs4ltQ4RAo2qAKDTUprNSpcaoiCglQY9brm8mp06NgCeKtkf WeXQcLjwdtGHJs1LoOO3R60= =SiZt -----END PGP SIGNATURE-----
+-------[ Tres Seaver ]---------------------- | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | Andrew Milton wrote: | > +-------[ Andreas Jung ]---------------------- | > | | > | Effective from Zope 2.9 I marked FCGI as deprecated - both in the | > | documentation and through a deprecation warning in the sources. Please note | > | that it does not mean that the FCGI might go away automatically in the | > | future. This is basically a reminder for people using FCGI that there is a | > | better way (in our opinion) to run Zope under Apache than using FCGI. | > | > This of course assumes the entire world runs Apache. | | How big do you imagine the set is of people running Zope via FastCGI who | are *not* running Apache as the front end? Now how big is the | intersection of that set with the set of folks who have (and will use) | commit access to Zope? | | The real issue from Andreas' point of view is that *nobody* who helps | maintain Zope also knows and uses FastCGI; *he* used to be the person | who did know it (per http://www.fastcgi.com/), but no longer. | | Without such a person or persons, Zope cannot really claim to support | FastCGI at all. My issue isn't with the loss of FCGI (although I know a few hosting companies that might be upset at that, perhaps you can scare them into funding its maintainence d8). It's with the way that there is 'a real issue' and a 'made up justification'. If there's noone around who can maintain it, then just say that. Don't say there's 'a better way', because I can guarantee you the people using FCGI are using it for a reason, and there isn't a "better way" for them. P.S. I can imagine a pretty big set of people running Zope via FCGI who are not running Apache.. I can also imagine that magical code fairies fight with magical code trolls to the death to decide what pieces of code stay and which pieces go. -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
If there's noone around who can maintain it, then just say that. Don't say there's 'a better way', because I can guarantee you the people using FCGI are using it for a reason,
I haven't seen anyone come up with real justification for using FCGI...
I can imagine a pretty big set of people running Zope via FCGI who are not running Apache.. I can also imagine that magical code fairies fight with magical code trolls to the death to decide what pieces of code stay and which pieces go.
Uh? I'm not sure whether to ask for some of what you're on or just run away screaming ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
--On 5. Dezember 2005 07:51:17 +0000 Chris Withers <chris@simplistix.co.uk> wrote:
Andrew Milton wrote:
If there's noone around who can maintain it, then just say that. Don't say there's 'a better way', because I can guarantee you the people using FCGI are using it for a reason,
I haven't seen anyone come up with real justification for using FCGI...
FCGI is deprecated effective Zope 2.9. -aj
Chris Withers wrote at 2005-12-5 07:51 +0000:
Andrew Milton wrote:
If there's noone around who can maintain it, then just say that. Don't say there's 'a better way', because I can guarantee you the people using FCGI are using it for a reason,
I haven't seen anyone come up with real justification for using FCGI...
The original poster explained his wish to retain FCGI: It reuses an existing connection between Apache and Zope while (he thinks and I might believe it) the recommended "mod_proxy" way each time opens a new connection. Thus, FastCGI might be more efficient. -- Dieter
Dieter Maurer wrote:
The original poster explained his wish to retain FCGI:
It reuses an existing connection between Apache and Zope while (he thinks and I might believe it) the recommended "mod_proxy" way each time opens a new connection.
Thus, FastCGI might be more efficient.
Show me some evidence proving that fcgi or mod_proxy is the significant limiting performance factor in a setup involving zope and I'll take this seriously ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wed, 07 Dec 2005 01:39:37 -0800, Chris Withers <chris@simplistix.co.uk> wrote:
Dieter Maurer wrote:
The original poster explained his wish to retain FCGI: It reuses an existing connection between Apache and Zope while (he thinks and I might believe it) the recommended "mod_proxy" way each time opens a new connection. Thus, FastCGI might be more efficient.
Show me some evidence proving that fcgi or mod_proxy is the significant limiting performance factor in a setup involving zope and I'll take this seriously ;-)
FWIW, we did some rudimentary benchmarking with Zope + Apache using mod_proxy vs. Zope + FastCGI + lighttpd (a very fast and lightweight web server). There was no difference in performance since Zope is so slow in the first place - so it didn't make any difference. -- _____________________________________________________________________ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _____________________________________________________________________ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone
Am Mittwoch, den 07.12.2005, 09:39 +0000 schrieb Chris Withers:
Dieter Maurer wrote:
The original poster explained his wish to retain FCGI:
It reuses an existing connection between Apache and Zope while (he thinks and I might believe it) the recommended "mod_proxy" way each time opens a new connection.
Thus, FastCGI might be more efficient.
Show me some evidence proving that fcgi or mod_proxy is the significant limiting performance factor in a setup involving zope and I'll take this seriously ;-)
The funny thing is - performance isnt really the pro of fcgi over http. Its really more about transporting header and environment data from zope to apache, which is kinda limited with mod_proxy. (Think alternative authentication, ssl ) Tino.
...
The funny thing is - performance isnt really the pro of fcgi over http. Its really more about transporting header and environment data from zope to apache, which is ^^^^^^^^^^^^^^ actually I meant apache to zope.
I go and get some coffee... Tino
Tino Wildenhain wrote:
The funny thing is - performance isnt really the pro of fcgi over http. Its really more about transporting header and environment data from zope to apache, which is kinda limited with mod_proxy. (Think alternative authentication, ssl )
Indeed, and it's funny that the guy complaining was complaining about performance rather than this, which seems like quite a reasonable justification for keeping FCGI support. Of course, it still doesn't change the fact that no-one knows how /wants to maintain it ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 12/10/05, Tino Wildenhain <tino@wildenhain.de> wrote:
Am Mittwoch, den 07.12.2005, 09:39 +0000 schrieb Chris Withers:
Dieter Maurer wrote:
The original poster explained his wish to retain FCGI:
It reuses an existing connection between Apache and Zope while (he thinks and I might believe it) the recommended "mod_proxy" way each time opens a new connection.
Thus, FastCGI might be more efficient.
Show me some evidence proving that fcgi or mod_proxy is the significant limiting performance factor in a setup involving zope and I'll take this seriously ;-)
The funny thing is - performance isnt really the pro of fcgi over http. Its really more about transporting header and environment data from zope to apache, which is kinda limited with mod_proxy. (Think alternative authentication, ssl )
This was my reason for going with fastcgi instead of modproxy. I wanted zope to also log the http header data from the client. I want to have zope make some decisions based on the user agent. If modproxy can preserve ALL the request headers that I suppose I can use it. I somewhat understand fastcgi. I don't understand everything mod-proxy does... (well, its more magical than fastcgi) Tino.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- David Bear What's the difference between private knowledge and public knowledge?
David Bear schrieb:
On 12/10/05, *Tino Wildenhain* <tino@wildenhain.de <mailto:tino@wildenhain.de>> wrote:
Am Mittwoch, den 07.12.2005, 09:39 +0000 schrieb Chris Withers: > Dieter Maurer wrote: > > The original poster explained his wish to retain FCGI: > > > > It reuses an existing connection between Apache and Zope > > while (he thinks and I might believe it) the recommended > > "mod_proxy" way each time opens a new connection. > > > > Thus, FastCGI might be more efficient. > > Show me some evidence proving that fcgi or mod_proxy is the significant > limiting performance factor in a setup involving zope and I'll take this > seriously ;-)
The funny thing is - performance isnt really the pro of fcgi over http. Its really more about transporting header and environment data from zope to apache, which is kinda limited with mod_proxy. (Think alternative authentication, ssl )
This was my reason for going with fastcgi instead of modproxy. I wanted zope to also log the http header data from the client. I want to have zope make some decisions based on the user agent. If modproxy can preserve ALL the request headers that I suppose I can use it. I somewhat understand fastcgi. I don't understand everything mod-proxy does... (well, its more magical than fastcgi)
mod_proxy passes all relevent headers. Even user-agent. But serious web development should never try to depend on the useragent string. (it can and will be faked - and you will have a hard time to know all possible user-agents out there (I occassionally browse as google - you would be surpriced what you see :)) The only hard part is ssl-client certificate or other apache side auth information. Auth-headers (basic auth) are of course passed.
Bitte schick das auf die Liste. Ich habe keine Lust solche Diskussionen privat zu führen. Danke, Andreas --On 28. November 2005 14:05:22 +0100 Gerhard Schmidt <estartu@ze.tum.de> wrote:
On Mon, Nov 28, 2005 at 12:43:44PM +0000, Jens Vagelpohl wrote:
On 28 Nov 2005, at 12:28, Gerhard Schmidt wrote:
I know there is a way to do just the same with mod_proxy, but mod_proxy does open new connection for every request while fastcgi uses the same connection for all requests. The is no problem on low load. But with growing load, this can become a Problem.
Well, it's not "a way to do it", it's *the* way.
Thats a real good argument. There is no *the* way. Every situation is different and having as mutch possibilities as possible is allways the best way to do it.
I highly doubt that your assertion about using more connections than just one is a problem, under any circumstance. All very large production sites that I ever dealt with use mod_rewrite/mod_proxy. It simply is not a problem. Or do you have proof?
Im runnig a very large site with 40000 users and a peak arround 60 Requests per second. Having to call connect end all the routines that come with it is quite an increased load. Why. FastCGI work perfectly and efficiently. Thats exactly the usecase Fastcgi was developed for.
In none of the Postings is an reason why FastCGI ist bad and therefore not supported in the future. Just to say "so it is" is not an Answer.
So my question is still there.
Bye Estartu
------------------------------------------------------------------------- --- Gerhard Schmidt | Nick : estartu IRC : Estartu | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | EMail: estartu@augusta.de | on request Germany | |
participants (11)
-
Alexander Limi -
Andreas Jung -
Andrew Milton -
Chris Withers -
David Bear -
Dieter Maurer -
Gerhard Schmidt -
Jens Vagelpohl -
Paul Winkler -
Tino Wildenhain -
Tres Seaver