Hacker News Reader

Comment by tlrobinson | Hacker News Reader

"easily wrapped around a 'regular' program"

Sounds like you want CGI :)

Yes, "static CGI" if such a thing was a thing :-). I've got a thttpd tree that I do this sort of hack in (these are great for monitoring large numbers of servers for example).

I don't understand (and am interested). What's "static" about it? With Apache and mod_rewrite and CGI, I could make the functionality you want (which is, of course, completely not low footprint, but I don't understand how what you want is different from CGI).

Static in the sense that it always executes the one function (doesn't load it from disk, its part of the executable) and so there is never any risk that some other path might get you 'out' of the docs directory and into the cgi_bin directory. So in this case static is code for 'compiled in' versus 'dynamically loaded.'

Like a statically linked HTML document? I know you're talking C code, but I could imagine some kind of HTML to C "compiler" that could you then statically link into an executable. Then you could have a full website that ran as a single static executable, including CGI-esque calls.

It's actually rather easy: http://www.linuxjournal.com/content/embedding-file-executabl...

That's cool! I wonder if this would be (much) faster than just letting nginx or this embedded httpd read the files directly and serve them. I would hope that the OS or server would cache things enough to make it unnecessary, but it would be interesting to find out.

HTML isn't that big, so if you used linked resources, it would be pretty simple to make a C program and compile it to a binary for any purely "static" site.

That's how the Kore web server works ( https://kore.io/ ); it makes you generate a static.h file at compile time that contains all of you your static content.

But like you say, I have to wonder if it actually makes a difference performance-wise. The kernel will cache the static file data anyways. The only improvement I can see is maybe to avoid having to look up file metadata (length and mtime)? Or to avoid a syscall?

Openresty is a good option for this - Lua in nginx.

The apache module to do this is like a screenful of code. Really, mod_perl or mod_python or mod_wsgi can do this with dynamic languages, the code is only loaded once (per child in prefork apache). Your apache config can avoid reading the filesystem all together.

As long as you have a web server that can load modules and be invoked on specific URL requests, you can embed this.

I'm more familiar with Windows, but Linux should be similar. If your application is executed often, then it's pages should be in memory already, and not necessarily need to be read from disk. In terms of execution, if it's a compiled binary, it should be fast enough, if you need more, what you want is a lightweight application server anyway.

The problem with regular old CGI is that for every request the web server gets it has to run some binary file and setup a new thread for that every single time. Also, that's ignoring the filesystem overhead which isn't negligible even if it's already cached. You're basically turning your web server into a glorified shell script and even though all of your CGI scripts are compiled it's still horribly inefficient. FastCGI on the other hand is basically like giving the web server a socket to a persistent process that runs the associated code in an existing thread instead of having to spawn a new one on every request.

Basically FastCGI is like having another server just for your dynamic content while the web server sits in front of it and takes care of hosting the static content and deferring to the FastCGI server when appropriate.

I'm specifically saying that the File System overhead is negligible for files/executables that are frequently accessed. Windows uses RAM to cache these files... Setting up a Process to execute said file vs a service that stays running is a different story.

Sounds like you want AOLServer.

http://www.aolserver.com/docs/devel/c/c-overview.html

Reply on news.ycombinator.com