10 ms·

I hate to be the young whippersnapper parrotting buzzwords, but CGI is theoretically supposed to lend itself really easily to deployment onto serverless runtime

I hate to be the young whippersnapper parrotting buzzwords, but CGI is theoretically supposed to lend itself really easily to deployment onto serverless runtimes, right?

hamandcheese 9y ago
CGI predates serverless by quite a bit. It’s basically a standard interface for a web server to let any arbitrary executable handle a HTTP request. https://en.m.wikipedia.org/wiki/Common_Gateway_Interface https://en.m.wikipedia.org/wiki/Common_Gateway_Interface
- pkage 9y ago
  Non mobile link: https://en.wikipedia.org/wiki/Common_Gateway_Interface https://en.wikipedia.org/wiki/Common_Gateway_Interface
  - nurettin 9y ago
    Is there a non-censored link? :-(
    - grzm 9y ago
      Here's one I found. http://www.oreilly.com/openbook/cgi/ch01_01.html http://www.oreilly.com/openbook/cgi/ch01_01.html
    - ohmygeek 9y ago
      How about this one? http://archive.is/1WmHz http://archive.is/1WmHz
    - hennsen 9y ago
      Whats censored in that page?
      - grzm 9y ago
        Based on their profile, I gather they're referring to the fact that Wikipedia is blocked in Turkey. https://en.wikipedia.org/wiki/2017_block_of_Wikipedia_in_Turkey https://en.wikipedia.org/wiki/2017_block_of_Wikipedia_in_Tur...
    - lazysheepherd 9y ago
      You can use use wiki zero mirror (www.0wikipedia.org sufficient to put a zero before any wiki link) until illiterate government of superstitious majority hopefully disappear.
      - nurettin 9y ago
        Thanks, also works when subdomain is different
      - chrisweekly 9y ago
        +1 for the "0-prefix" tip; cool!
- elvinyung 9y ago
  I know that.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
pjc50 9y ago
CGI is one of those "simplest thing that could possibly work" tools: for every request to a specific url path, the webserver runs an executable. Headers passed in the environment, stdin and stdout plumbed to the network socket. Back before serverless, we called it shared hosting. Of course, fork() is not especially fast, so people came up with Fastcgi: persist the process and let it handle multiple requests. Then people started writing java where the startup time was prohibitive, and "application servers" like Tomcat came into being.
- sebcat 9y ago
  > Of course, fork() is not especially fast fork itself is pretty fast, relatively speaking (unless you have a large virtual address space and 4K pages or similar). fork+execve+process-runtime-initialization is much slower. On my X201 (anno 2010), with 10000 iterations, sequential fork+exit(0)-in-child+wait takes: $ /usr/bin/time ./forkfest 2,49 real 0,38 user 2,19 sys while sequential fork+execve("/usr/bin/true",...)-in-child+wait takes: $ /usr/bin/time ./forkfest2 10,99 real 3,10 user 7,94 sys EDIT: also, My X201 is clocked at 1199 MHz (50%) for power saving reasons
  - matthewaveryusa 9y ago
    Yes it's slower compared to a single multithreaded evented server, but that fork gives you process separation which is a huge security feature and resilient to one bad request taking down your whole server. You can aslo write your code blocking + single thread which is so simple and easy to debug
  - dfox 9y ago
    On paged systems fork() is usually reasonably fast, but for CGI you do fork()+exec() and while exec() is also reasonably fast, the stuff that the happens in child process between it's start and entry into main() (ie. dynamic linking, libc initialization) is somewhat on the slower side. (Not to mention interpreter startup for interpreted languages)
  - jimbokun 9y ago
icebraining 9y ago
Easily yes, but I don't think it would be efficient. AWS Lambda, from what I can tell, doesn't launch a new process for each request; instead, it just "freezes" the process between each request, and then call a function to handle it. In that regard, it's closer to FastCGI than CGI itself.
fuball63 9y ago
I'm actually working on this now: [1][2] CGI was abandoned because of the slowness of process forking, but with modern kernels, new compiled languages, and better reverse proxy servers, I believe that the speed difference is trivial in regards to the advantages: - Deployment can be done by simple file upload. - Process isolation adds security and reliability. - CGI scripts/binaries are vendor agnostic and can be run/tested locally - CGI scripts can use any language, are stateless, promote hyper modular design (aka functions) and are generally minimalistic in nature. [1] https://bigcgi.com/ https://bigcgi.com/ [2] https://github.com/bmsauer/bigcgi https://github.com/bmsauer/bigcgi
- tangent128 9y ago
  https://bigcgi.com/development https://bigcgi.com/development - "Fast-CGIish Integration" Are you thinking something like "FastCGI, except over stdin/out instead of a listening socket"? Since that sounds like it could work pretty efficiently if (unlike nginx's fcgi implementation) it supported multiplexing.
  - fuball63 9y ago
    I think what I meant by that was basically building a generic FCGI wrapper that could automatically scoop up generic CGI scripts and run them in a shared process automatically. Like this: https://github.com/gnosek/fcgiwrap https://github.com/gnosek/fcgiwrap I like the idea of communication via stdin/stdout though, I'll add that to my notes. I actually was going to remove that from the roadmap entirely, because lately I really like the process isolation and statelessness of regular CGI. Thanks for your comment!
- girvo 9y ago
  Those first two points apply (almost) to PHP. Probably the nicest parts of it are ease of deployment, and the isolated “throw the world away” process model per-request. I’ve played with SCGI myself in Nim, it’s quite fun to explore.
  - fuball63 9y ago
floatboth 9y ago
Yep, I've been thinking a lot about "serverless is pretty much CGI". But actually, Lambda can keep your server open to serve multiple requests without spawning new processes all the time. I realized that the key feature is not having the server open all the time, only when necessary. So I took systemd's socket activation idea and added socket deactivation, i.e. sending SIGTERM to the server after a period of inactivity: https://github.com/myfreeweb/soad https://github.com/myfreeweb/soad Plus, one of the things that really deserves more hype and popularity is CloudABI https://nuxi.nl https://nuxi.nl an ABI that lets you have one binary that runs on multiple operating systems as is and always runs sandboxed. The serverless runtime of my dreams just takes CloudABI binaries (packed with files in a tarball) that listen for HTTP on a given socket, and does the activation-deactivation thing to only run on demand :)

I hate to be the young whippersnapper parrotting buzzwords, but CGI is theoretically supposed to lend itself really easily to deployment onto serverless runtimes, right?

hamandcheese 9y ago

CGI predates serverless by quite a bit. It’s basically a standard interface for a web server to let any arbitrary executable handle a HTTP request. https://en.m.wikipedia.org/wiki/Common_Gateway_Interface https://en.m.wikipedia.org/wiki/Common_Gateway_Interface

pkage 9y ago
Non mobile link: https://en.wikipedia.org/wiki/Common_Gateway_Interface https://en.wikipedia.org/wiki/Common_Gateway_Interface
- nurettin 9y ago
  Is there a non-censored link? :-(
  - grzm 9y ago
    Here's one I found. http://www.oreilly.com/openbook/cgi/ch01_01.html http://www.oreilly.com/openbook/cgi/ch01_01.html
  - ohmygeek 9y ago
    How about this one? http://archive.is/1WmHz http://archive.is/1WmHz
  - hennsen 9y ago
    Whats censored in that page?
    - grzm 9y ago
      Based on their profile, I gather they're referring to the fact that Wikipedia is blocked in Turkey. https://en.wikipedia.org/wiki/2017_block_of_Wikipedia_in_Turkey https://en.wikipedia.org/wiki/2017_block_of_Wikipedia_in_Tur...
  - lazysheepherd 9y ago
    You can use use wiki zero mirror (www.0wikipedia.org sufficient to put a zero before any wiki link) until illiterate government of superstitious majority hopefully disappear.
    - nurettin 9y ago
      Thanks, also works when subdomain is different
    - chrisweekly 9y ago
      +1 for the "0-prefix" tip; cool!
elvinyung 9y ago
I know that.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

pjc50 9y ago

CGI is one of those "simplest thing that could possibly work" tools: for every request to a specific url path, the webserver runs an executable. Headers passed in the environment, stdin and stdout plumbed to the network socket. Back before serverless, we called it shared hosting. Of course, fork() is not especially fast, so people came up with Fastcgi: persist the process and let it handle multiple requests. Then people started writing java where the startup time was prohibitive, and "application servers" like Tomcat came into being.

sebcat 9y ago
> Of course, fork() is not especially fast fork itself is pretty fast, relatively speaking (unless you have a large virtual address space and 4K pages or similar). fork+execve+process-runtime-initialization is much slower. On my X201 (anno 2010), with 10000 iterations, sequential fork+exit(0)-in-child+wait takes: $ /usr/bin/time ./forkfest 2,49 real 0,38 user 2,19 sys while sequential fork+execve("/usr/bin/true",...)-in-child+wait takes: $ /usr/bin/time ./forkfest2 10,99 real 3,10 user 7,94 sys EDIT: also, My X201 is clocked at 1199 MHz (50%) for power saving reasons
- matthewaveryusa 9y ago
  Yes it's slower compared to a single multithreaded evented server, but that fork gives you process separation which is a huge security feature and resilient to one bad request taking down your whole server. You can aslo write your code blocking + single thread which is so simple and easy to debug
- dfox 9y ago
  On paged systems fork() is usually reasonably fast, but for CGI you do fork()+exec() and while exec() is also reasonably fast, the stuff that the happens in child process between it's start and entry into main() (ie. dynamic linking, libc initialization) is somewhat on the slower side. (Not to mention interpreter startup for interpreted languages)
- jimbokun 9y ago

icebraining 9y ago

Easily yes, but I don't think it would be efficient. AWS Lambda, from what I can tell, doesn't launch a new process for each request; instead, it just "freezes" the process between each request, and then call a function to handle it. In that regard, it's closer to FastCGI than CGI itself.

fuball63 9y ago

I'm actually working on this now: [1][2] CGI was abandoned because of the slowness of process forking, but with modern kernels, new compiled languages, and better reverse proxy servers, I believe that the speed difference is trivial in regards to the advantages: - Deployment can be done by simple file upload. - Process isolation adds security and reliability. - CGI scripts/binaries are vendor agnostic and can be run/tested locally - CGI scripts can use any language, are stateless, promote hyper modular design (aka functions) and are generally minimalistic in nature. [1] https://bigcgi.com/ https://bigcgi.com/ [2] https://github.com/bmsauer/bigcgi https://github.com/bmsauer/bigcgi

tangent128 9y ago
https://bigcgi.com/development https://bigcgi.com/development - "Fast-CGIish Integration" Are you thinking something like "FastCGI, except over stdin/out instead of a listening socket"? Since that sounds like it could work pretty efficiently if (unlike nginx's fcgi implementation) it supported multiplexing.
- fuball63 9y ago
  I think what I meant by that was basically building a generic FCGI wrapper that could automatically scoop up generic CGI scripts and run them in a shared process automatically. Like this: https://github.com/gnosek/fcgiwrap https://github.com/gnosek/fcgiwrap I like the idea of communication via stdin/stdout though, I'll add that to my notes. I actually was going to remove that from the roadmap entirely, because lately I really like the process isolation and statelessness of regular CGI. Thanks for your comment!
girvo 9y ago
Those first two points apply (almost) to PHP. Probably the nicest parts of it are ease of deployment, and the isolated “throw the world away” process model per-request. I’ve played with SCGI myself in Nim, it’s quite fun to explore.
- fuball63 9y ago

floatboth 9y ago

Yep, I've been thinking a lot about "serverless is pretty much CGI". But actually, Lambda can keep your server open to serve multiple requests without spawning new processes all the time. I realized that the key feature is not having the server open all the time, only when necessary. So I took systemd's socket activation idea and added socket deactivation, i.e. sending SIGTERM to the server after a period of inactivity: https://github.com/myfreeweb/soad https://github.com/myfreeweb/soad Plus, one of the things that really deserves more hype and popularity is CloudABI https://nuxi.nl https://nuxi.nl an ABI that lets you have one binary that runs on multiple operating systems as is and always runs sandboxed. The serverless runtime of my dreams just takes CloudABI binaries (packed with files in a tarball) that listen for HTTP on a given socket, and does the activation-deactivation thing to only run on demand :)