FastCGI support

[mapel]

Is there any way to use fastCGI with civetweb or is there any intent to implement that feature in the future?

Kind regards

mapel

[bel]

Currently there is no FastCGI support in CivetWeb - we have classical CGI support and (even faster as FastCGI) in-server modules for certain languages (server side Lua and JavaScript, extendible using the C API).

Up to now there was no request for FastCGI support. The website http://www.fastcgi.com/ disappeared some time ago (https://www.reddit.com/r/linuxadmin/comments/4bywjn/what_happened_to_fastcgicom/), and even in Apache mod_fastcgi has been discontinued (or replaced by mod_fcgi with a different threading model? https://www.apachelounge.com/viewtopic.php?t=4385). So I'm currently somewhat unsure about the status of FastCGI. It's definitely possible to add FastCGI support, but it's not on my short term TODO list at the moment - if there is a high demand, we should discuss it.

[mapel]

Ok, I was not aware of the situation surrounding FastCGI. As php feels a little bit slow with civetweb, I was hoping for some performance improvement with FastCGI.

I am pretty knew to the whole webserver thing, so excuse me please, if my question is dumb, but I noticed some websites and webapps access php over a local port like localhost:9200.

As I understand it that means php is always running and processes requests faster. Is that right and would that be an option for civetweb?

[bel]

A short comparison (not necessarily complete):

CGI:
- is a RFC standard (https://tools.ietf.org/html/rfc3875)
- for every connection you create a new process, sent the request to this process, read the response from there and forward it to the client
- so you create a lot of processes and have a lot of inter-process communications
- but you have as many processes as you need
- if the CGI process crashes, it only affects one connection
- if you use a blocking operation (reading something from a network drive) you only block one connection

Fast CGI:
- is not a RFC standard, and the website (http://www.fastcgi.com/) is gone, but it is still a common practice
- you have a limited number of processes: you pre-create one process and queue all requests there
- you gain speed, by not having to create a new process for every request
- but you queue (serialize) all requests, and still have a lot of inter-process communications

In-server module:
- you embed the language interpreter into the webserver
- every connection / every request has its own interpreter, so there is no need for serialization
- no inter-process communication
- basically as fast as you can get
- you cannot do it with every interpreter, in civetweb we only support Lua and JavaScript as server side scripting languages (and everything you can add using C/C++ callbacks)
- every connection is independent, so you can block, pause/abort/reorder processing, ...
- using C/C++ callbacks to extend an existing application with web capabilities is equivalent to in-server modules


So, FastCGI is faster than CGI (unless you use blocking operations in FastCGI), but in-server modules are even better.

FastCGI is currently not implemented - it would be possible to add it, but up to now just nobody has done it.
Personally I usually use C callbacks or Lua in-server modules, so there is no speed issue.