21–30 of 57 posts
Later converted those into fcgi and throughput increased drastically, like an increase of 10 times over previous.
But fcgi is a little bit tricky as your memory and resource leaks will accumulate, and if your program crashes, it will fault on subsequent requests too, and not just that one request as happens in cgi.
Earlier quoted context omitted.
Indeed, but: - when declaring routing in code, it's harder to shoot yourself in the foot. So many php sites expose what they should not, and .httaccess is rarely crafted correctly - renaming files don't change your website - coding locally doesn't require apache if your tooling don't need it for routing. No need for stuff like EasyPhp - python dev servers automatically reload for you on changes anyway - declaring rou…
None of the points you mention are an argument against CGI for me. But it is mostly a matter of taste. There is one point I would like to address though: "python is slow to start" Python is slow. Dead slow. But not to start: echo 'print(1)' > test.py; time for i in {1..100}; do python3 test.py > /dev/null; done Gives me 1.6s echo ' test.php; time for i in {1..100}; do php test.php > /dev/null; done Gives me 1.9s
Earlier quoted context omitted.
None of the points you mention are an argument against CGI for me. But it is mostly a matter of taste. There is one point I would like to address though: "python is slow to start" Python is slow. Dead slow. But not to start: echo 'print(1)' > test.py; time for i in {1..100}; do python3 test.py > /dev/null; done Gives me 1.6s echo ' test.php; time for i in {1..100}; do php test.php > /dev/null; done Gives me 1.9s
I'd say they are both slow. Try Perl, Tcl, Lua or some other interpreted language that starts fast, and you'll likely see something like 200-300ms for the equivalent commands to above.
echo 'print 1' > test.perl; time for i in {1..100}; do perl test.perl > /dev/null; done
Clearly the winner!
Earlier quoted context omitted.
None of the points you mention are an argument against CGI for me. But it is mostly a matter of taste. There is one point I would like to address though: "python is slow to start" Python is slow. Dead slow. But not to start: echo 'print(1)' > test.py; time for i in {1..100}; do python3 test.py > /dev/null; done Gives me 1.6s echo ' test.php; time for i in {1..100}; do php test.php > /dev/null; done Gives me 1.9s
I'd say they are both slow. Try Perl, Tcl, Lua or some other interpreted language that starts fast, and you'll likely see something like 200-300ms for the equivalent commands to above.
For example, you can also compare to a C program not doing much, overhead-wise:
/usr/bin/time bash -c 'for i in {1..100}; do /bin/true; done'
Even that 700 microseconds is a high number, from glibc & dynamic linking mostly. If you
echo 'int main(int ac,char**av){return 0;}' > /tmp/true.c
musl-gcc -static -O2 /tmp/true.c -o /tmp/true
In benchmarking scenarios requiring more elaboration than makes sense in an HN comment, I see times as low as 140 microsec per run on that same machine/OS. In fact, as you push things to low overhead extremes, you can easily see the impact of how much environment variable data is in play (`env -i` vs. not).
It is true that Python start-up time is not that bad compared to a "mean diameter of the Internet in milliseconds" which is probably the relevant time scale for CGIs, but it's probably not so small as to be truly negligible, esp. once imports are happening.
Also, Python3 remains quite a bit slower (1.7X slower on that same machine) to start-up than Python2 even after more than a decade of promises to claw back start-up performance.
Meanwhile, on the other side of the comparison, starting up a Julia REPL seems to take quite a bit longer than the Python 16 ms..Like 340ms or 20X longer.
So, the overarching point of this overlong post is just a follow-up/supporting of @tyingq's "compared to what?" with a little more detail.
That's it, I'm sold. I'm building my startup around CGI scripts! /s
It wasn't a typical use case, but my current business leant on a CGI script for a few years at the start. I needed to let users sign up for an email list and rather than spin up an entire app for that, I wrote a Ruby script and ran it CGI-style on httpd because the rest of the site was all static HTML files anyway. Would a dev team have ever taken such an approach? No. But when you're a solo founder, it's a privilege…
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…
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.
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 default php behavior.
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.
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…
The reason is that it gets incredible hard to maintain, and almost impossible to test.
> The only way of optimizing Ruby is not to use Ruby lol
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…
Not many write PHP code like this anymore, except for perhaps some small one off projects or legacy. The reason is that it gets incredible hard to maintain, and almost impossible to test.
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…
> "one url, one file" by letting Apache handle the routing Source of many issues when someone forgets the "include auth.php" equivalent in that one specific file. (not theoretical, this happened so many times) > I have to restart the application to see changes I make. https://adamj.eu/tech/2021/12/16/introducing-django-browser-...