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

41–50 of 57 posts

Re: Myths About CGI Scalability

#41

Post by CodesInChaos »

How well does that sharing work on Windows nowadays with ASLR being popular? Traditionally Windows uses non relocatable exe-files, and DLLs that require fixups on relocation where you lose sharing for every page containing a fixup. I assume that nowadays relocatable exe-files are more common to enable ASLR.

But do modern compilers targeting Windows prefer position independent code over fixups? Or are fixups of x86-64 code rare enough and clustered enough that it doesn't really matter?

Re: Myths About CGI Scalability

#44

Post by duskwuff »

tjpnz wrote: post #6
TekMol wrote: post #3

I really like the PHP approach of "one url, one file" by letting Apache handle the routing. I love to build a whole application by just putting a bunch of php files into a directory. And I hate that in a typical Python+Django application, I have to restart the application to see changes I make. But apart from that, Python is the nicer language. So I would like to do more web dev in Python. Most Python devs get red fa…

Perhaps give mod_python a look. Tried and tested but I wouldn't want to write an application like that in 2022 when I could use Flask or Fast API.

mod_python is dead. Last release was in 2013, and according to the web site, "there is no plan for additional releases".

Re: Myths About CGI Scalability

#45

Post by icedchai »

CodesInChaos wrote: post #42
sgt wrote: post #11

That's it, I'm sold. I'm building my startup around CGI scripts! /s

Just build it on AWS lambda, so you pay for a whole VM for each concurrent request. Progress!

I was going to say that Lambda is the new CGI (except Lambda is generally a worse developer experience and often higher latency.)

Re: Myths About CGI Scalability

#46

Post by KronisLV »

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…

> Its just... not really that much simpler than FCGI / php-fpm in my experience.

I mean, there are a lot of options to run PHP out there: for sites that don't get a lot of traffic, something like mod_php in Apache might just be enough, because configuring php-fpm means that you'll have another process running for executing PHP and you'll need to proxy traffic to it.

Personally, I recently tried building my own Ubuntu container images for all of the software that I want to run (excluding databases) and found this in particular to be a pain point. I could get php-fpm installed, used Supervisord to launch multiple processes in the container, but PHP was only executed when I built the container image locally, yet failed to execute PHP when the container image was built on the CI server.

I have no idea why exactly that was, even though I tried documenting that mess on my blog "Containers are broken": https://blog.kronis.dev/everything%20is%20broken/containers-...

Now, that was probably a build issue (that I managed to resolve by just moving PHP over to Nginx, which seemed to integrate with no issues for whatever random reason), but operationally mod_php seems way simpler, just something that plugs into your web server and lets you process requests directly - even if in a less scalable manner.

Then again, nowadays you have multiple MPM choices: https://httpd.apache.org/docs/2.4/mpm.html

So as far as I can tell, many folks might be using something like mpm_event, which generally performs a bit more efficiently than mpm_prefork or something like it.

But using PHP just for CGI, without even trying to integrate with a web server per se? I'm not sure, but given the example above, I'm sure that there are reasons for doing that as well, much like my example of moving one step back from php-fpm, to mod_php if need be.

Re: Myths About CGI Scalability

#47

Post by irq-1 »

duskwuff wrote: post #44
tjpnz wrote: post #6

Earlier quoted context omitted.

Perhaps give mod_python a look. Tried and tested but I wouldn't want to write an application like that in 2022 when I could use Flask or Fast API.

mod_python is dead. Last release was in 2013, and according to the web site, "there is no plan for additional releases".

No new development but it still runs. If you can get by with the older version of python that's embedded, it's a good start for someone who is learning.

Re: Myths About CGI Scalability

#48

Post by duskwuff »

irq-1 wrote: post #47
duskwuff wrote: post #44

Earlier quoted context omitted.

mod_python is dead. Last release was in 2013, and according to the web site, "there is no plan for additional releases".

No new development but it still runs. If you can get by with the older version of python that's embedded, it's a good start for someone who is learning.

> If you can get by with the older version of python that's embedded, it's a good start for someone who is learning.

I'd have to disagree with that. Teaching a new developer how to use a tool that's already on its last legs is not setting them up for success.

Re: Myths About CGI Scalability

#49

Post by 9dev »

bastawhiz wrote: post #36
TekMol wrote: post #3

I really like the PHP approach of "one url, one file" by letting Apache handle the routing. I love to build a whole application by just putting a bunch of php files into a directory. And I hate that in a typical Python+Django application, I have to restart the application to see changes I make. But apart from that, Python is the nicer language. So I would like to do more web dev in Python. Most Python devs get red fa…

> 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…

I would argue this is mostly a thing of the past. Properly configuring your production environment is a thing for all languages, and stuff like that simply doesn’t happen with a modern framework, ie. Anything written after 2010.

Re: Myths About CGI Scalability

#50

Post by withinboredom »

bastawhiz wrote: post #36
TekMol wrote: post #3

I really like the PHP approach of "one url, one file" by letting Apache handle the routing. I love to build a whole application by just putting a bunch of php files into a directory. And I hate that in a typical Python+Django application, I have to restart the application to see changes I make. But apart from that, Python is the nicer language. So I would like to do more web dev in Python. Most Python devs get red fa…

> 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?
Post reply on HN