Unpopular opinion: AWS lambda is basically equivalent to CGI. The web has come full circle.
Is this supposed to be a bad thing?
No, it's just ironic. It also means that AWS could potentially reuse standard (F)CGI interfaces.
Websocketd
221–230 of 233 posts
Re: Websocketd
#222Earlier quoted context omitted.
The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows
I see this argument all the time but its not the fork() that is the most expensive anymore, its the actual program initialization after the fork(). If your app is non trivial (lets say a websocket based chat server that needs to persist messages to a DB and use pubsub to sync them to other processes) it probably needs a connection to a database, a connection to a cache server like Redis or Memcached, etc, or perhaps…
Well, you can manage resources by shared memory and semaphores. That will make nearly all of the environment setting time go away. Better yet if you just serialize the processes and assign resources to a serial number.
What is just another way to make a NxM server, so maybe forget about it...
Re: Websocketd
#223Earlier quoted context omitted.
I find it ironic that people will complain about milliseconds for a fork and talk about the time for context switches... and then serve their pages using an interpreted language that is an order of magnitude slower than it could be in a compiled language...
Who did that? I saw no one talking about interpreted languages here.
The comment immediately below the GP that claims that performance is relative literally says that you don't have to care about forking in Node.js.
Re: Websocketd
#224Earlier quoted context omitted.
Sometimes you know your scale. Say you have a website for your local area D&D club. You know that nobody outside a 20 mile radius is going to ever really bother looking at your stuff. And you know that there are about 200 people interested in D&D in this area. You need a contact form on your site to email you when someone has a question. How many connections at most would you realistically expect to have to process i…
More than you’d assume, once you factor in search engine crawlers, miscellaneous bots and automated tools that bad actors run to probe websites looking for vulnerabilities. However if still expect CGI to stand up against that. Performance arguments aside and given the type of site you describe, wouldn’t it be more convenient for the developer to use Wordpress or one of those website builder as a service things instea…
Some kinds of API endpoints and webhooks are exactly what I love CGI for—when what I want to do is exactly “bind an HTTP endpoint to a shell command.”
Re: Websocketd
#225Earlier quoted context omitted.
More than you’d assume, once you factor in search engine crawlers, miscellaneous bots and automated tools that bad actors run to probe websites looking for vulnerabilities. However if still expect CGI to stand up against that. Performance arguments aside and given the type of site you describe, wouldn’t it be more convenient for the developer to use Wordpress or one of those website builder as a service things instea…
Some kinds of API endpoints and webhooks are exactly what I love CGI for—when what I want to do is exactly “bind an HTTP endpoint to a shell command.”
I agree but I'd never do that for a production system because it's far to risky from a security standpoint. For personal projects, sure. However even there I'd IP whitelist (wherever possible), sit the CGI behind an authentication screen and put log monitoring on there (eg fail2ban) to auto-blacklist any IPs identified as potentially abusing the endpoint.
If this isn't all stuff you already have set up on your dev environment then you might find hardening CGI becomes as much work as re-writing those tools in a more secure framework.
Re: Websocketd
#226Earlier quoted context omitted.
The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows
I see this argument all the time but its not the fork() that is the most expensive anymore, its the actual program initialization after the fork(). If your app is non trivial (lets say a websocket based chat server that needs to persist messages to a DB and use pubsub to sync them to other processes) it probably needs a connection to a database, a connection to a cache server like Redis or Memcached, etc, or perhaps…
You can prefork. That is a tried and true method. And why do you need to create so many connections? Certainly you can architect the solution better than that.
Re: Websocketd
#227Earlier quoted context omitted.
Yes! Every mention of CGI also gets a sneer and a reminder of how poorly it scales, but nothing I do requires scale in that sense. "In production" doesn't always mean "hundreds of requests per second." Every road doesn't need 8 lanes.
I’ve had developers say this before when building public websites and it has cost us in lost revenue when the site has gone offline or cost us lots in virtual hardware having to scale the number of servers available to meet higher than expected volumes of traffic. Don’t get me wrong, I'm not suggesting that everyone should be building their site like it’s Facebook or Google, but when every public website is already s…
You cannot serve the whole internet without cloud scale resources anyway. So what does it matter if your
application is 10K/s less capable than an optimized
version? You pay for another instance. For 5k more time and energy yearly you save .026 an hour. Congrats.
Re: Websocketd
#228Earlier quoted context omitted.
Then you run a GC and dirty all your pages.
GC usually runs on a separate thread right? Isn't it true you shouldn't run fork() when you have a multithreaded program?
It's probably not safe to fork() from most frameworks threads (OpenMP) and is hard to make safe for complicated parallel processing. But if you control the flow of execution and minimize mutex and critical section(s) it can be done withal. Several examples of thread served queues performing user defined actions upon message receipt
to include fork() + exec() come to mind.
Re: Websocketd
#229If you really wanted to follow UNIX philosophy, why not build atop xinetd? for example... simply accept stdin and stdout as I/O streams by default, but don't provide a network mechanism.
You can put websocketd behind xinetd. xinetd doesn't talk websocket, so you still need to "provide a network mechanism" to bridge the incoming connection and the client's streams.
> xinetd doesn't talk websocket
Why not extend xinetd so that it can interact with websockets?
Re: Websocketd
#230Earlier quoted context omitted.
You don't need a server like Apache or Nginx. Your code can just bind to 80/443 directly.
Yes you can but that has nothing to do with what I asked.
If you get the same answer three times but don't think any of them answer your question, maybe consider that you're the one failing to communicate.