Hacker News Reader

Comment by z92 | Hacker News Reader

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.

View on HN

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%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.

Thank God I thought I was the only one left.

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

[2]: https://github.com/toshic/libfcgi

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/

[2] https://github.com/spc476/mod_blog

Wow! Why C? For fun? Practice? Just what you know?

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.

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.

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

Astronomical calculations which can be very calculation heavy and depend on the geographical location of the requester, therefore can't be cached.

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.

Here is the C library that I have used in the past:

https://sourceforge.net/p/libccgi/wiki/Home/

Isn’t modern PHP much faster though?

Not for "heavy calculation loads."

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

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.

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.

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

And and if you scrap it and build some custom webserver or nginx plugin or Apache module it can be even faster or maybe something like IncludeOS which makes your application logic part of a minimal kernel ... If that's your aim. In most cases development time however is more valuable than pure execution time. (Even Facebook survived quite long in PHP, till it was wothwhile for them to move to their own thing)

Anyways comparison by GP was between a custom CGI program and PHP and not other things.

Thanks for IncludeOS, that sounds interesting...

On Facebook: I'm willing to bet a switch to binary from PHP is one magnitude less of processing power required, and an early switch would've cut their server requirements by 90%. Not sure which would've been cheaper, the C devs or all those extra servers burning electricity to interpret a language during runtime.

EDIT: And that's just an economic incentive. From an ecological perspective, it's borderline criminal for a website as massive as Facebook to be running PHP.

By switching to HipHop for PHP and later HHVM they saved lots of servers. 90% is a bit too much (consider: they went "services" first, where different tasks were done in different languages in independent services) And yes, for the ecological argument that is true (even more ecological it would be to shut down Facebook ... )

However using PHP allowed them to hire lots of staff quickly and adapt to changed requirements quickly. Which is economical valuable. Finding the right time for a switch is simpler in a retrospective though ;-)

(I have no insight to Facebook, but was heavily involved in the PHP project and talked to different Facebook engineers privately and professionally)

Reply on news.ycombinator.com