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

151–160 of 233 posts

Re: Websocketd

#151

Post by delinka »

sureaboutthis wrote: post #147
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.

This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do some languages have their own deep connections into the server flow that makes them faster? I just don't understand this.

If you’re using CGI or FCGI, then you’re using a general web server that is probably serving lots of different applications.

These days, folks often write the app to contain a web server. Write your app in JavaScript, pull in a dependency that serves HTTP, write enough code to route requests and start the server listening- welcome to Node. Python and Ruby offer the same. Swift gets this functionality from Kitura and Vapor. I’ve experienced C and C++ varieties.

Back in the day when Apache was seriously hot, mimicking today’s architecture would have meant writing an Apache module - the app would then live within the server and no communication channel/pipe/socket/fork/spawn would be required.

Re: Websocketd

#152

Post by sureaboutthis »

delinka wrote: post #151
sureaboutthis wrote: post #147

Earlier quoted context omitted.

This is something that confuses me. Servers offer CGI and fastCGI and if you aren't using those to interface with your own code, how do you do so otherwise? Do some languages have their own deep connections into the server flow that makes them faster? I just don't understand this.

If you’re using CGI or FCGI, then you’re using a general web server that is probably serving lots of different applications. These days, folks often write the app to contain a web server. Write your app in JavaScript, pull in a dependency that serves HTTP, write enough code to route requests and start the server listening- welcome to Node. Python and Ruby offer the same. Swift gets this functionality from Kitura and…

Yes but the poster, above, is complaining about using CGI with a server. My question is, if you're not using CGI/fastCGI with Apache or nginx for example, what is he suggesting should be used instead?

Re: Websocketd

#153

Post by nabla9 »

inglor wrote: post #125
geocar wrote: post #115

Earlier 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

8ms per fork means you can only accept 125 connections per second. (per core) That means it's only viable for connections where the connection is very long lived and messages are very sparse (because context switches).

If you use websocket for short lived connections, you are doing something wrong.

--

Meta observation:

Maybe this is the bane of smartphone era and small screens, but the context of the discussion seems to disappear instantly.

Subject: websockets > forking processes > .. aaand the websocket context is lost and we are talking generally about forks in web applications with growing thread.

Re: Websocketd

#154

Post by delinka »

sureaboutthis wrote: post #152
delinka wrote: post #151

Earlier quoted context omitted.

If you’re using CGI or FCGI, then you’re using a general web server that is probably serving lots of different applications. These days, folks often write the app to contain a web server. Write your app in JavaScript, pull in a dependency that serves HTTP, write enough code to route requests and start the server listening- welcome to Node. Python and Ruby offer the same. Swift gets this functionality from Kitura and…

Yes but the poster, above, is complaining about using CGI with a server. My question is, if you're not using CGI/fastCGI with Apache or nginx for example, what is he suggesting should be used instead?

Ok, lemme spell it out: bundling the app and the server together; that’s what’s implied.

Re: Websocketd

#155

Post by magicalhippo »

masklinn wrote: post #120
arendtio wrote: post #112

Earlier quoted context omitted.

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,…

Not sure how it is in Linux, but in Windows it's only threads that can execute code. Spawning a process will cause the OS to create a thread for it as well.

Re: Websocketd

#156

Post by saagarjha »

justinclift wrote: post #128
saagarjha wrote: post #106

Earlier quoted context omitted.

Friendly reminder that not everyone is in a position where they can create pull requests against random projects: they might not have time, or clearance from their company's legal department, or…

??? Note it was a question. As you mention, not everyone can do so (etc).

The question looked like "why are aren't you making a PR for this".

Re: Websocketd

#157

Post by zozbot123 »

fulafel wrote: post #142
arendtio wrote: post #112

Earlier quoted context omitted.

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?

Traditionally in Unix and Windows contexts, "processes" means separate memory address spaces and OS-guaranteed isolation, and "threads" mean threads of execution that have shared access to one address space. Erlang processes are threads as seen by the OS, but the Erlang runtime implements process-y restrictions that enforce isolation and forbid shared memory between Erlang processes that do infact exist as threads in…

The Unix programming model does not forbid shared memory between processes. It just gives them separate address spaces, but aside from that you can do whatever you want. Yes, separating address spaces makes processes memory safe by default, but it's not just Erlang that enforces this sort of memory safety programmatically within a single address space. What about Rust, or Haskell. They don't refer to threads, or to runtime-scheduled fibers created via async programming or via the work-stealing model, as "processes".

Re: Websocketd

#158

Post by geocar »

inglor wrote: post #125
geocar wrote: post #115

Earlier 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

8ms per fork means you can only accept 125 connections per second. (per core) That means it's only viable for connections where the connection is very long lived and messages are very sparse (because context switches).

Cores are cheap: I've got 200, and a lot of that cost is page faults.

It also means you should use posix_spawn instead of fork+exec since you can control when the page faults occur better.

Re: Websocketd

#159

Post by sureaboutthis »

delinka wrote: post #154
sureaboutthis wrote: post #152

Earlier quoted context omitted.

Yes but the poster, above, is complaining about using CGI with a server. My question is, if you're not using CGI/fastCGI with Apache or nginx for example, what is he suggesting should be used instead?

Ok, lemme spell it out: bundling the app and the server together; that’s what’s implied.

Which comes back to my question. Can one do that with apache and nginx? I'm pretty sure I've seen methods for this in Apache but only the paid version of nginx. Am I wrong?

Re: Websocketd

#160

Post by fulafel »

zozbot123 wrote: post #157
fulafel wrote: post #142

Earlier quoted context omitted.

Traditionally in Unix and Windows contexts, "processes" means separate memory address spaces and OS-guaranteed isolation, and "threads" mean threads of execution that have shared access to one address space. Erlang processes are threads as seen by the OS, but the Erlang runtime implements process-y restrictions that enforce isolation and forbid shared memory between Erlang processes that do infact exist as threads in…

The Unix programming model does not forbid shared memory between processes. It just gives them separate address spaces, but aside from that you can do whatever you want. Yes, separating address spaces makes processes memory safe by default, but it's not just Erlang that enforces this sort of memory safety programmatically within a single address space. What about Rust, or Haskell. They don't refer to threads, or to r…

I don't know about Haskell parallelism primitives, but in Rust the normal thing to do is to share references to the same memory location correctness-checked by the type system. The correcness guarantees don't come from private storage, but from compiler made proofs done on the control flow / dataflow. So it wouldn't make sense to say "processes".

Erlang is a dynamic language without any such type system checks. The process separation is all just based on the fact that it's impossible to get or make a shared value, it's just not a concept in the language. You send and receive messages, which implies a copy, and you faff around with local values inside your process.

Re shared-memory support in Unix: Yeah, you have escape hatches from the memory models in Unix processes, and Rust, and probably Erlang and Haskell. But they're exceptions and safe to ignore when discussing terminology to describe the platform's native model. Also the Unix shared memory APIs were a late addition to the OS and everyone agrees they're ugly :)

Post reply on HN