| |||||||||||||
PHP 5.4.0 releasedPHP 5.4.0 releasedPosted Mar 3, 2012 0:42 UTC (Sat) by pboddie (subscriber, #50784)In reply to: PHP 5.4.0 released by ibukanov Parent article: PHP 5.4.0 released
I didn't think anyone used FastCGI any more, but I guess the Web 2.0 brigade has revived the technology. My impression was that the Python community would rather you used WSGI, and before that, even things like mod_python (which got a certain amount of unfair criticism given the benefits it offered) were favoured over FastCGI.
The last time I recall any prominent mention of FastCGI in the Python Web scene was back in the days of Zope 1.x with a brief note mentioning that it was unreliable and not really recommended. I stopped following such matters closely several years later (and thus several years ago) and FastCGI's reputation hadn't exactly improved over that time, but it's possible that it has returned in the caching-front-end-intensive Web architectures of today.
With regard to running Python Web applications in long-running process servers, it should be sufficient for those servers to support WSGI as the API for applications. Then, there shouldn't be any portability issues with regard to deployment in a range of environments.
(Log in to post comments)
PHP 5.4.0 released Posted Mar 3, 2012 1:16 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Hm?
FastCGI is a nice interface, not bad at all for high-load services. It's just that WSGI is little more 'pythonic'.
PHP 5.4.0 released Posted Mar 5, 2012 10:41 UTC (Mon) by pboddie (subscriber, #50784) [Link]
I guess it had something to do with the robustness of the FastCGI implementations back in the day, then. As for portability, switching server technologies shouldn't be an issue: most frameworks support WSGI, and most server adapters expose WSGI. Five years ago or so it was completely possible to write portable Python Web applications - I even wrote a framework for doing just that, pre-WSGI - but if you decided to just write code for, say, Django, I'm pretty sure the deployment opportunities based on WSGI are good enough.
PHP 5.4.0 released Posted Mar 3, 2012 11:42 UTC (Sat) by ibukanov (subscriber, #3942) [Link]
If one consider alternatives for apache like lighttpd or nginx, then FastCGI comes naturally. I was surprised how easy it was to run WordPress, FluxBB and custom PHP applications over FastCGI with lighttppd each under its own user account while consuming much less resources than the same applications running under the same account as the apache server.
With Python and Perl that required much more efforts if the application is written with mod_python/mod_perl in mind.
PHP 5.4.0 released Posted Mar 4, 2012 10:18 UTC (Sun) by niner (subscriber, #26151) [Link]
With Perl you use frameworks like Catalyst, Dancer or Mojolicuous to write web applications and with them you can switch from mod_perl to fastcgi and vice versa without changing a single line of code. In addition, you get an integrated development webserver and support for running over plain old CGI and it's trivial to scale up by serving static files with a different server like ngnix or lighttpd.
It cannot possibly get easier than that.
PHP 5.4.0 released Posted Mar 4, 2012 11:15 UTC (Sun) by ibukanov (subscriber, #3942) [Link]
> With Perl you use frameworks
The problem starts when it is necessary to quickly port to FastCGI badly written and unmaintained scripts that are not written using those frameworks. With PHP it just works with default settings. With Perl it requires to manually fix those. So despite all its limitations and ugliness PHP was a winner in my case due to universality of its default configuration.
|
|||||||||||||