Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Myths About CGI Scalability

z505.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Myths About CGI Scalability

#51

Post by bastawhiz »

withinboredom wrote: post #50
bastawhiz wrote: post #36

Earlier quoted context omitted.

> Are there any arguments to not do this in production? When the way the code is run is also the vehicle for returning output, you necessarily end up in a situation where you expose bad output to the user. This is an insanely common problem with PHP: warnings, errors, and stack traces are regularly returned in HTTP responses by default . Consider PHP: the output of the code (echo, closing the PHP tag, etc) gets dumpe…

Php’s default production configuration doesn’t output any errors. Perhaps you were running the default dev configuration in production?

I publish a WordPress plugin and have worked with PHP for twenty years, and given the number of sites I've investigated that output notices and errors, what you've said seems false. Even if the stock version that is officially distributed doesn't output this by default, a wild number of hosts do.

Re: Myths About CGI Scalability

#52

Post by habibur »

tyingq wrote: post #26
habibur wrote: post #20

Earlier quoted context omitted.

PHP is now a days ran as fcgi, just like how Python, Ruby or Go runs. The Apache mod days have been left in the past. That you can't render a python script.py like php's script.php more likely has to do with language construction difference between the two.

>> That you can't render a python script.py like php's script.php more likely has to do with language construction difference between the two. You can, actually, and how close it is to the way php works is all to do with the fastcgi handler, and little to do with the language. Wsgi has configuration like WSGIScriptAlias, WSGIScriptAliasMatch, and WSGIScriptReloading that would make it almost exactly the same as defau…

> I suppose it may not run efficiently that way, but it would run. And you don't have the built-in html templating with php, where any html file is also a valid php file.

Indeed.

On an abstract level anything can be done. Efficiency is the question.

Re: Myths About CGI Scalability

#53

Post by somat »

fastcgi is the real elephant in the room. cgi has a reason for existing. a standard calling convention for loading a process with http request info. but fastcgi??? it is network server protocol. "hey guys, let transform our http network protocol into another almost but not quite the same network protocol" for crying out loud, why? just stick with http.

I am almost convinced the only reason it exists is that when it came time to replace the process per request to a single process that would handle multiple requests, people had a hard time thinking about it as a server, so when fastcgi came around and said hey we are cgi(it's not) but fast, they bought the name recognition. it almost appears like a scam but I am not sure who the grifters are.

Re: Myths About CGI Scalability

#54

Post by withinboredom »

bastawhiz wrote: post #51
withinboredom wrote: post #50

Earlier quoted context omitted.

Php’s default production configuration doesn’t output any errors. Perhaps you were running the default dev configuration in production?

I publish a WordPress plugin and have worked with PHP for twenty years, and given the number of sites I've investigated that output notices and errors, what you've said seems false. Even if the stock version that is officially distributed doesn't output this by default, a wild number of hosts do.

Belief isn’t required: https://github.com/php/php-src/blob/master/php.ini-productio...

I suspect many people don’t RTFM or have any idea what they are doing with php (or js) because they are historically “entry-level” languages.

Re: Myths About CGI Scalability

#55

Post by effie »

somat wrote: post #53

fastcgi is the real elephant in the room. cgi has a reason for existing. a standard calling convention for loading a process with http request info. but fastcgi??? it is network server protocol. "hey guys, let transform our http network protocol into another almost but not quite the same network protocol" for crying out loud, why? just stick with http. I am almost convinced the only reason it exists is that when it c…

> for crying out loud, why? just stick with http.

Because on a busy server, it's better to have lower number of interpreter processes than one per HTTP request. So multiple requests need to be passed to a single interpreter process, so there has to be some multiplexing of the requests into single data channel. Also some aspects of HTTP are traditionally handled by the frontend web server, and some requests do not reach the language interpreter (various access denials, client errors, etc.) So simple HTTP between web server and language interpreter on the same machine is not necessarily a particularly great idea; it would inhibit the development and even performance. It makes sense to parse text once and then pass data between programs in binary form. Fastcgi was good enough, so it stuck.

Re: Myths About CGI Scalability

#56

Post by effie »

dragontamer wrote: post #34

Wait, does anyone really use CGI instead of FCGI these days? Let alone like, php-fpm pools and the like? The general gist I've come up with myself is 1000x processes for fork()/exec() pattern, 100,000 threads for pthreads, and 10,000,000 golang / async / whatever. Maybe I'm off by a magnitude or two, but that's my general assumption. If you've got less than 1000x processes, CGI probably is fine. But I can't think of…

The mainstream view is that php-fpm has better performance than old CGI, and is much better for domain isolation (no suexec hacks needed). But it is also more buggy in operation. It hangs from time to time, requires monitoring that restarts FPM when that happens.

Old CGI is nice in that you can easily set up Apache to launch any kind of executable, not just the one lagnuage script that the Fastcgi process manager supports. So you can have bash// python scripts, C binaries, all accesible through the web page.

Re: Myths About CGI Scalability

#57

Post by antonvs »

throwaway787544 wrote: post #16
antonvs wrote: post #9

Earlier quoted context omitted.

Since it's talking about Perl CGI websites, the decade for which it's relevant was the 1990s. Phil Greenspun's book Database Backed Websites was published in 1997, and its coverage of CGI already started seeming rather quaint over the next few years as better approaches took over.

Perl was widely used for websites through at least 2005, mod_perl being the dominant expression of it.

It was widely used but also widely criticized by that point. Dead man walking, basically.
Post reply on HN