Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Websocketd

websocketd.com

Post reply on HN
Print view View original

111–120 of 233 posts

Re: Websocketd

#111

Post by sebcat »

MrTonyD wrote: post #98
sebcat wrote: post #97

Earlier quoted context omitted.

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.

prior thread with some ad-hoc measurements: https://news.ycombinator.com/item?id=16714403

Re: Websocketd

#112

Post by arendtio »

Jedi72 wrote: post #94
jchw wrote: post #26

This 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.

AFAIK, those are not 'processes' in terms of operating system processes, but instead some kind of parallel running tasks within the Erlang VM (much closer to threads).

Edit: If you think I am wrong, could you please explain what is wrong?

Re: Websocketd

#113

Post by pjmlp »

cat199 wrote: post #57
gok wrote: post #10

Ok I know the software-today-is-so-bloated trope is overplayed but... "the UNIX way"? The compiled Linux x86_64 binary is 7 megabytes. All of System V combined was not that big.

... and yet Unix was critiqued for being written in a high level language instead of assembler

UNIX was originally written in Assembly, B and C came later.

And why should it be criticized? Outside AT&T, people were writing OSes in high level languages since 1961.

Re: Websocketd

#114

Post by laumars »

askmike wrote: post #110
laumars wrote: post #108

Earlier quoted context omitted.

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…

Used in production doesn't always mean used by all users of a public app that might go viral. If you have an app with an admin interface/CMS/monitoring interface and you know there won't be 50 administrators for your app before the end of the year this works great (assuming you can reverse proxy this to add auth or something).

> Used in production doesn't always mean used by all users of a public app that might go viral.

Hence why I specifically said "public website". Intranets and other IP whitelisted resources are clearly a different topic entirely. Sites only intended for 50 administrators but are not hidden behind a firewall make me nervous for a whole other set of reasons but I accept that's got to happen sometimes (but even there, most of the best / developer friendly CRUD platforms these days aren't CGI so there is little reason to use CGI even for that specific use case).

Re: Websocketd

#115

Post by geocar »

jchw wrote: post #26

This 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.

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

Re: Websocketd

#116

Post by _pmf_ »

jashmatthews wrote: post #71
jchw wrote: post #26

This 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.

> processes and forking are relatively expensive This and "async is always faster" are two things which are no longer true on modern hardware. Forking a process on Linux uses the same clone() syscall as creating a thread so forking a small binary takes only tens of microseconds, leaving plenty of time for https://eli.thegreenplace.net/2018/launching-linux-threads-a...

> Forking a process on Linux uses the same clone() syscall as creating a thread

The conclusion to be drawn is "Linux threads are costly", not "Linux processes are cheap".

Re: Websocketd

#118

Post by iforgotpassword »

geocar wrote: post #115
jchw wrote: post #26

This 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.

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

Related: when I worked on a server (on linux) that would spawn threads for new connections that were mostly short lived, I tried to use a thread pool instead. Hand crafted, with push and pop both O(1). It was still mostly slower than just spawning a new thread every time.

Re: Websocketd

#119

Post by lexicality »

vidarh wrote: post #104
hendry wrote: post #99

Earlier quoted context omitted.

Socket connection alone is too expensive. IRC shows us that maintaining a reliable socket for most folks is next to impossible.

On the contrary. IRC shows that maintaining a consistent network where every part can always reach every other part is tricky, but the most common problem with irc networks is not clients getting booted off, but net-splits that usually automatically resolves pretty quickly. That they're visible to clients is an issue with how channels spans servers and how operator status and channel membership is tied to who happens…

I disagree. I've not seen a netsplit in months, but clients constantly timing out and rejoining is a fact of life.

Re: Websocketd

#120

Post by masklinn »

arendtio wrote: post #112
Jedi72 wrote: post #94

Earlier quoted context omitted.

Unless you develop in Elixir/Erlang where you can spawn millions of concurrent processes.

AFAIK, those are not 'processes' in terms of operating system processes, but instead some kind of parallel running tasks within the Erlang VM (much closer to threads). Edit: If you think I am wrong, could you please explain what is wrong?

AFAIK there is very little difference between processes and threads in linux (both are instances of task_struct), the variability in implementation details specific makes that use for classification useless, and thus the only possible separation of any use is semantics: the difference between processes and threads is whether they share internal state (generally / by default).

Erlang's don't, thus processes. Go's do, thus threads.

Post reply on HN