is it me, or does the site look really similar to letsencrypt.org? I looked on both sites and neither say they're using a template.
If someone really cares to investigate, the Letsencrypt.org website (Hugo based) is here for starting with:
Websocketd
91–100 of 233 posts
Re: Websocketd
#92Earlier quoted context omitted.
They tried green threads years and years ago in Java and then reversed course, and M:N was also a thing on NetBSD years ago. I wonder why Go is working where the others went away from it?
I am pretty sure Java's historical use of green threads was an issue of portability and not performance. They used traditional threading primitives. Java's decision to use green threads may have actually made a lot of sense in an era when consumer computers typically only had one physical thread to begin with. Go on the other hand is based on CSP principles and a threading model that looks like actors. The threading…
The reason why this gets more attention in Go than elsewhere is because it's unusual for the kind of language Go is (lot lower level than something like Erlang). Everything else in Go is really "better C so long as it's not C++", but goroutines are an experiment in their own right.
Re: Websocketd
#93Earlier quoted context omitted.
SVR4 came out 30 years ago. I think it's time to let it go.
Aah the joys of false progressivism. I hear that representing the absence of value as a number was invented about 6000 years ago, perhaps we should abandon that as antiquated as well.. also, to wit, a Unix kernel of recent vintage: $ uname -msr OpenBSD 6.3 amd64 $ du -skc bsd.rd bsd 9664 bsd.rd 12912 bsd 22576 total vs, say, a Linux kernel of recent vintage: $ uname -msr Linux 4.9.0-8-amd64 x86_64 $ du -skc /boot/vml…
This turned me on.
Re: Websocketd
#94This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
Unless you develop in Elixir/Erlang where you can spawn millions of concurrent processes.
Re: Websocketd
#95This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
Depends on what your needs are. In many cases, you need to scale to a few dozen connections per day, and simplicity is far more valuable than performance. If you're pushing the limits of performance, any off the shelf solution is probably not going to scale as well as it could for your specific workload.
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.
Re: Websocketd
#96Earlier quoted context omitted.
They tried green threads years and years ago in Java and then reversed course, and M:N was also a thing on NetBSD years ago. I wonder why Go is working where the others went away from it?
> I wonder why Go is working where the others went away from it? Quite frankly, because Go developers don't learn from other's mistakes and reinvent square wheels. Kernel threads will always be better and faster than usermode threads. This is because any inefficiency in threading comes from the scheduler. Your usermode scheduler will always necessarily be slower and worse; it just makes so much sense to put your sche…
The Go concurrency model can't possibly be implemented in the kernel because it trades some isolation guarantees for better performance.
Re: Websocketd
#97Earlier quoted context omitted.
But websocket connections are usually long lasting. So the cost of the fork is less important.
It's not so much the fork but the memory cost. Each of those subprocesses has at least one call stack = 2 megabytes of memory. 2 megabytes per connection is many many orders of magnitude more that you would use in an asynchronous server.
1) that's virtual size, and most likely (depending on OS/cfg) COW (assuming no call to execve).
2) that's a default - most systems allow tuning
You can have pretty decent performance with forking models if you 1) have an upper bound for # of concurrent processes 2) have an input queue 3) cache results and serve from cache even for very small time windows. Not execve'ing is also a major benefit, if your system can do that (e.g. no mixing of threads with forks). In forking models, execve+runtime init is the largest overhead.
It will not beat other models, but forking processes offer other benefits such as memory protection, rlimits, namespace separation, capsicum/seccomp-bpf based sandboxing, ...
YMMV
Re: Websocketd
#98Earlier quoted context omitted.
It's not so much the fork but the memory cost. Each of those subprocesses has at least one call stack = 2 megabytes of memory. 2 megabytes per connection is many many orders of magnitude more that you would use in an asynchronous server.
1) that's virtual size, and most likely (depending on OS/cfg) COW (assuming no call to execve). 2) that's a default - most systems allow tuning You can have pretty decent performance with forking models if you 1) have an upper bound for # of concurrent processes 2) have an input queue 3) cache results and serve from cache even for very small time windows. Not execve'ing is also a major benefit, if your system can do…
I think you guys are both right. Back in the days when I measured UNIX performance, it was fork that was expensive due to memory allocation - but not the memory itself. It takes time to allocate all the page tables associated with the memory when you are setting up for the context switch. But I should admit that it was a long time ago that I traced that code path.
Re: Websocketd
#99This is the second or third "it's CGI again" thing I've seen in the past year. While these things are cool and definitely have their place, it's still worth noting that process per connection scales fairly poorly, simply because processes and forking are relatively expensive, and therefore it's probably unwise to deploy something like this in production anymore. It is what it is, I suppose.
But websocket connections are usually long lasting. So the cost of the fork is less important.
Socket connection alone is too expensive.
IRC shows us that maintaining a reliable socket for most folks is next to impossible.
Re: Websocketd
#100i’ve been using this in production to stream logs to a web console (~2,000 sets of logs distributed across 4 server with about 350 active connections at a time) and have never had any issues
How do you know that you haven't had any issues?