5 ms·

Written as if it's a 25 year old tech no one uses now? I still use cgi scripts. Though these aren't "scripts", rather compiled binaries written in C. That mad

by z92 7y ago

Written as if it's a 25 year old tech no one uses now? I still use cgi scripts. Though these aren't "scripts", rather compiled binaries written in C. That made some of the pages with heaviest calculations, load in under a second, which were taking more than 10 seconds in PHP.

hnarn 7y ago
Do you have any more information available on this? I'm curious about the use case for using compiled binaries directly over PHP.
- z92 7y ago
  Astronomical calculations which can be very calculation heavy and depend on the geographical location of the requester, therefore can't be cached.
- Bubbadoo 7y ago
  It sounds as though the compiled binaries optimize the compute portion, which the interpreted php code was taking 10 secs to run. It's still likely running as a cgi process, that is as a fork/exec in a separate address space. If you're using mod_php or one of the many php engines available for modern web servers, you're already enjoying a scalability and execution time improvement over standard cgi. Except with compute code, apparently.
- chasil 7y ago
  Here is the C library that I have used in the past: https://sourceforge.net/p/libccgi/wiki/Home/ https://sourceforge.net/p/libccgi/wiki/Home/
spiderfarmer 7y ago
Isn’t modern PHP much faster though?
- pgcj_poster 7y ago
  Not for "heavy calculation loads."
- chasil 7y ago
  For many purposes, it is not, and some of these use cases will be addressed in PHP 8. https://news.ycombinator.com/item?id=19535564 https://news.ycombinator.com/item?id=19535564
- klingonopera 7y ago
  Correct me if I'm wrong, but PHP is interpreted at runtime, whereas a binary file... is directly executed? Essentially, for the same task, PHP could never be as fast as a binary, because of the overhead of processing the language itself. Creating a binary in place of PHP code is essentially reducing the calculatory load of a webpage to a minimum during runtime.
  - johannes1234321 7y ago
    It won't be faster, but could be fast enough™. Mind also: With a CGI process for each request the process has to be created, program loaded, runtime linked and executed. With any semi-modern PHP setup the PHP process is running already (be it mod_php, fastcgi, fpm, ...) and the "compiled" version of the script is in memory ready to be executed (opcode caching) thus PHP can win in startup time. If you then out the heavy calculation in a C extension module you get simple templating around it in quite fast. Future versions of PHP might also receive some form of a JIT (experiments are well progressing) an ideal JIT might even beat a C program (as it can compile to the specific CPU and can analyse and optimize the hotpath; see also hotspot and similar Java runtimes) PHP won't be there (as the jit has to call too often into PHP runtime) but there's room for future iterations.
    - klingonopera 7y ago
      > Mind also: With a CGI process for each request the process has to be created, program loaded, runtime linked and executed. Yeah, that's CGI though, FCGI alleviates this by persistently running a single process/service/application that listens to the port and acts according to the received HTTP headers. Whatever PHP can optimize can thus be done directly with FCGI as well. You can load everything the webpage needs into memory and just pipe that through to the user, and it would only need to read disk once at startup (or if you update the sources, but that's another issue). The downside is of course the increased development time and complexity you'd have to invest... EDIT2: Another downside specific to FCGI is that it is OS-dependent, because it needs to interact with the host in order to listen to a port, something that doesn't affect normal CGI because all you need there is stdout.
gepiti 7y ago
Thank God I thought I was the only one left.
martinrame 7y ago
I still use CGI in most of my web apps, some of them SaaS applications, and them performs pretty well. The author mentions CGI overhead. Well, that's relative, please read this: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Myths%20About%20CGI%20Scalability http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Myths%20About%20... One important side effect of CGI is the fact that if one route crashes (in a REST api for example) the CGI finishes its execution and nobody is harmed. On the other side, with server daemons, one bug can kill the whole app.
spc476 7y ago
i still run my blog [1] via CGI [2]. I've never really had a problem with it in 20 years. [1] http://boston.conman.org/ http://boston.conman.org/ [2] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog
- winrid 7y ago
  Wow! Why C? For fun? Practice? Just what you know?
  - z92 7y ago
    Because it's still the best language for writing library routines along with a header file, which then can be used from most other languages with least runtime overhead.
  - spc476 7y ago
    When I started writing it back in 1999, it was what I knew. I also had a C library for dealing with CGI scripts I wrote from the mid-90s. Also, for several years my website was run off a 486 I had colocated at a company my friend was running, so there was a performance issue as well.
klingonopera 7y ago
I dabbled in PHP to create a blog[1], learnt C at work in the meantime, stumbled upon (F)CGI and am in the midst of (voluntarily) redoing my blog in C. Does anyone have any links to a nice FCGI library? The official site went down ages ago AFAIK, and whatever I have[2] isn't working out of the box, at least not on Windows... (Yes, I have a Linux server and I will deploy the FCGI on it too, but I develop on a Windows machine...) [1]: https://morgen.ist/blog.php https://morgen.ist/blog.php [2]: https://github.com/toshic/libfcgi https://github.com/toshic/libfcgi

by z92 7y ago

hnarn 7y ago

Do you have any more information available on this? I'm curious about the use case for using compiled binaries directly over PHP.

z92 7y ago
Astronomical calculations which can be very calculation heavy and depend on the geographical location of the requester, therefore can't be cached.
Bubbadoo 7y ago
It sounds as though the compiled binaries optimize the compute portion, which the interpreted php code was taking 10 secs to run. It's still likely running as a cgi process, that is as a fork/exec in a separate address space. If you're using mod_php or one of the many php engines available for modern web servers, you're already enjoying a scalability and execution time improvement over standard cgi. Except with compute code, apparently.
chasil 7y ago
Here is the C library that I have used in the past: https://sourceforge.net/p/libccgi/wiki/Home/ https://sourceforge.net/p/libccgi/wiki/Home/

spiderfarmer 7y ago

Isn’t modern PHP much faster though?

pgcj_poster 7y ago
Not for "heavy calculation loads."
chasil 7y ago
For many purposes, it is not, and some of these use cases will be addressed in PHP 8. https://news.ycombinator.com/item?id=19535564 https://news.ycombinator.com/item?id=19535564
klingonopera 7y ago
Correct me if I'm wrong, but PHP is interpreted at runtime, whereas a binary file... is directly executed? Essentially, for the same task, PHP could never be as fast as a binary, because of the overhead of processing the language itself. Creating a binary in place of PHP code is essentially reducing the calculatory load of a webpage to a minimum during runtime.
- johannes1234321 7y ago
  It won't be faster, but could be fast enough™. Mind also: With a CGI process for each request the process has to be created, program loaded, runtime linked and executed. With any semi-modern PHP setup the PHP process is running already (be it mod_php, fastcgi, fpm, ...) and the "compiled" version of the script is in memory ready to be executed (opcode caching) thus PHP can win in startup time. If you then out the heavy calculation in a C extension module you get simple templating around it in quite fast. Future versions of PHP might also receive some form of a JIT (experiments are well progressing) an ideal JIT might even beat a C program (as it can compile to the specific CPU and can analyse and optimize the hotpath; see also hotspot and similar Java runtimes) PHP won't be there (as the jit has to call too often into PHP runtime) but there's room for future iterations.
  - klingonopera 7y ago
    > Mind also: With a CGI process for each request the process has to be created, program loaded, runtime linked and executed. Yeah, that's CGI though, FCGI alleviates this by persistently running a single process/service/application that listens to the port and acts according to the received HTTP headers. Whatever PHP can optimize can thus be done directly with FCGI as well. You can load everything the webpage needs into memory and just pipe that through to the user, and it would only need to read disk once at startup (or if you update the sources, but that's another issue). The downside is of course the increased development time and complexity you'd have to invest... EDIT2: Another downside specific to FCGI is that it is OS-dependent, because it needs to interact with the host in order to listen to a port, something that doesn't affect normal CGI because all you need there is stdout.

gepiti 7y ago

Thank God I thought I was the only one left.

martinrame 7y ago

I still use CGI in most of my web apps, some of them SaaS applications, and them performs pretty well. The author mentions CGI overhead. Well, that's relative, please read this: http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Myths%20About%20CGI%20Scalability http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Myths%20About%20... One important side effect of CGI is the fact that if one route crashes (in a REST api for example) the CGI finishes its execution and nobody is harmed. On the other side, with server daemons, one bug can kill the whole app.

spc476 7y ago

i still run my blog [1] via CGI [2]. I've never really had a problem with it in 20 years. [1] http://boston.conman.org/ http://boston.conman.org/ [2] https://github.com/spc476/mod_blog https://github.com/spc476/mod_blog

winrid 7y ago
Wow! Why C? For fun? Practice? Just what you know?
- z92 7y ago
  Because it's still the best language for writing library routines along with a header file, which then can be used from most other languages with least runtime overhead.
- spc476 7y ago
  When I started writing it back in 1999, it was what I knew. I also had a C library for dealing with CGI scripts I wrote from the mid-90s. Also, for several years my website was run off a 486 I had colocated at a company my friend was running, so there was a performance issue as well.

klingonopera 7y ago

I dabbled in PHP to create a blog[1], learnt C at work in the meantime, stumbled upon (F)CGI and am in the midst of (voluntarily) redoing my blog in C. Does anyone have any links to a nice FCGI library? The official site went down ages ago AFAIK, and whatever I have[2] isn't working out of the box, at least not on Windows... (Yes, I have a Linux server and I will deploy the FCGI on it too, but I develop on a Windows machine...) [1]: https://morgen.ist/blog.php https://morgen.ist/blog.php [2]: https://github.com/toshic/libfcgi https://github.com/toshic/libfcgi