3 ms·

I'm working on an experimental function as a service based on CGI apps. It has a lot of advantages of the article: - Process isolation - Close to hardware -

I'm working on an experimental function as a service based on CGI apps. It has a lot of advantages of the article: - Process isolation - Close to hardware - No cold start But it also has some advantages like: - Any language, including compiled languages - Local testing, backed by a standard I am still experimenting with the scaling potential; my biggest concern is memory requirements. Currently I'm writing the project's blog using the project, and then am going to do some performance tests. It's hosted on a 5 dollar digital ocean instance at bigcgi.com. [edited for formatting]

jchw 8y ago
How would this not suffer from similar issues to Lambda? The start times are going to be worse per request than application servers today because all of the initialization can no longer be amortized. Long before containers became the hot new thing, people were using FastCGI to amortize these costs, and importantly, Scale - CGI requires expensive process creation on every request. You can't take advantage of fast, usermode context switching like with Goroutines or event-based architectures like Node.js because each request is a process in old-school CGI. And how doesn't that put you to square 1 with isolation? Cloudflare is running multi-tenant loads; you ideally want to have fine grained control on resource utilization and access controls. With CGI, you pretty much have to reinvent Docker to get the same level of isolation... I'm not sure I follow how this is superior to other solutions except for that CGI is easier to test locally.
- fuball63 8y ago
  A fast-cgi implementation is something I've looked into if plain CGI is not fast enough. Initially I want to see what exactly the performance comparison is with plain CGI, and then iterate from there. As for resource utilization/constraints, it runs on freebsd and uses rctl to limit memory usage and number of processes. One thing I want to find out is how to balance user resource constraints with the total load of the shared server.
  - jchw 8y ago
    Oh, I see - so freebsd jails are used for this. At least for process isolation that seems like a solid approach. Still, I do wonder how much of the problem with containers is container overhead. To me a big difference is about what costs can be amortized. With CGI, pretty much every cost is paid at every request. With long running daemons, the per request overhead is removed. With Cloudflare's functions, the scheduling, request, and startup overhead are (theoretically) removed, leaving mostly just execution. With just CGI there's some win since you can drop the scheduling overhead, but I think you would probably lose that advantage as soon as you hit the upper limit where forking per request stops scaling. With FastCGI you can enable better scaling but since you now have to manage long running processes, you are officially in the scheduling business, though you could probably beat container scheduler like Kubernetes in terms of raw overhead. I don't know. Maybe this is a good idea, but I'll admit my first impression was mostly "isn't this just CGI as it always was?"

jchw 8y ago

How would this not suffer from similar issues to Lambda? The start times are going to be worse per request than application servers today because all of the initialization can no longer be amortized. Long before containers became the hot new thing, people were using FastCGI to amortize these costs, and importantly, Scale - CGI requires expensive process creation on every request. You can't take advantage of fast, usermode context switching like with Goroutines or event-based architectures like Node.js because each request is a process in old-school CGI. And how doesn't that put you to square 1 with isolation? Cloudflare is running multi-tenant loads; you ideally want to have fine grained control on resource utilization and access controls. With CGI, you pretty much have to reinvent Docker to get the same level of isolation... I'm not sure I follow how this is superior to other solutions except for that CGI is easier to test locally.

fuball63 8y ago
A fast-cgi implementation is something I've looked into if plain CGI is not fast enough. Initially I want to see what exactly the performance comparison is with plain CGI, and then iterate from there. As for resource utilization/constraints, it runs on freebsd and uses rctl to limit memory usage and number of processes. One thing I want to find out is how to balance user resource constraints with the total load of the shared server.
- jchw 8y ago
  Oh, I see - so freebsd jails are used for this. At least for process isolation that seems like a solid approach. Still, I do wonder how much of the problem with containers is container overhead. To me a big difference is about what costs can be amortized. With CGI, pretty much every cost is paid at every request. With long running daemons, the per request overhead is removed. With Cloudflare's functions, the scheduling, request, and startup overhead are (theoretically) removed, leaving mostly just execution. With just CGI there's some win since you can drop the scheduling overhead, but I think you would probably lose that advantage as soon as you hit the upper limit where forking per request stops scaling. With FastCGI you can enable better scaling but since you now have to manage long running processes, you are officially in the scheduling business, though you could probably beat container scheduler like Kubernetes in terms of raw overhead. I don't know. Maybe this is a good idea, but I'll admit my first impression was mostly "isn't this just CGI as it always was?"