6 ms·

Exactly, also I do not understand the comparison with apache. Apache can be configured to spawn one process per connection. You also could call a thread a "serv

by jontro 11y ago

Exactly, also I do not understand the comparison with apache. Apache can be configured to spawn one process per connection. You also could call a thread a "server" in it's own, so it's just a matter of playing with words. Also if an apache process dies it will not crash other requests

signa11 11y ago
> Also if an apache process dies it will not crash other requests can you have 2m Apache processes on your machine ?
- jontro 11y ago
  Well that would depend how long you run it for. They don't have to be simultaneous. It wouldnt make much sense to recycle the process for each request however. MaxConnectionsPerChild defines how often the process is recycled
  - klibertp 11y ago
    > They don't have to be simultaneous. Now you're just moving a goalpost. We're talking about Erlang processes - you can have millions of them simultaneously. > It wouldnt make much sense to recycle the process for each request however. It does make a great deal of sense from the fault-tolerance perspective. It also helps security. I have an unpleasant feeling that you don't know much about Erlang and its philosophy. The "one process per connection" architecture has many benefits; it's a canonical way of getting concurrency and parallelism on Unix systems, for example. The problem is the way OSes handle and schedule processes, it simply doesn't work with a very large number of them. Erlang implements its own kind of processes, which enforce the same constraints os OS-level processes without taking megs of RAM each and without being pressed after spawning a few thousand processes.
    - jontro 11y ago
      What I'm saying is that it's misleading to call one process a web server when they really are saying "How we handle 2 million simultaneous web requests". Also I would be very interested in reading such a writeup. There are many different approaches to dealing with it (i.e. on thread per connection / one process / poll based approch). I certainly can see the benefits of having it in lightweight threads called processes in this context.
      - toolz 11y ago
        >it's misleading to call one process a web server How is that even slightly misleading? That's exactly what many web servers on erlang do.
      - klibertp 11y ago
        > What I'm saying is that it's misleading to call one process a web server when they really are saying [...] No. It's simply a terminology used in Erlang, there's nothing misleading in it, once you know the definition. I mean, there is very specific thing called "server" in Erlang: http://erlang.org/doc/man/gen_server.html http://erlang.org/doc/man/gen_server.html and also "processes" are described here: http://erlang.org/doc/reference_manual/processes.html http://erlang.org/doc/reference_manual/processes.html What's highly misleading is using more general definitions of such words instead of Erlang-specific meanings. This is a conversation about Erlang and it makes sense to use the terms accepted in Erlang; you can't blame anyone for the fact that some of these terms have meanings different than you'd expect.
        Vendan 11y ago
        It's misleading because there are now 2 different definitions of the exact same word at work. It's a computer running a process running an Erlang VM that is then running multiple Erlang processes. It is completely reasonable to be annoyed at that. Many languages have a concept of threading in userspace rather then kernel space, but they don't just call it threading, they give it another name so that it can be distinguished from the existing concept. For example, stackless python's tasklets, Go's goroutines, green-threads.
  - 59nadir 11y ago
    > Well that would depend how long you run it for. They don't have to be simultaneous. The long way of saying "No, I can't, but I really don't want to accept that there might be a better model for this than my out of the box Apache setup."
- janvidar 11y ago
  I suppose this depends on your machine.
  - 59nadir 11y ago
    What if there was a model where it depended less heavily on your machine because of over 20 years of development with the goal of providing stable, robust systems aimed specifically at allowing you to run many things in parallel? What if the framework/API for it was developed for production systems from the beginning, meaning its API was made singularly for being able to easily spawn, manage and control these processes? The whole point of this article is that there is an architecture behind this and that this architecture is believed to be generally useful.
- laumars 11y ago
  Theoretically yes. Pragmatically no. There comes a point when it makes more sense to scale sideways (more OS instances) instead of up (more processes on beefier hardware). It's no secret that Apache isn't the leanest of HTTP daemons, but that's really a separate point to the argument of whether you can reasonably argue a process as a web server.
derefr 11y ago
Apache was a bad analogy. There is a thing that needs to be multi-process and fault-tolerant with the default case of badly-written code tossing out more state than just your own session, but it's not a web server that works like that. Instead, it's a "web application server", like Puma is for Rails apps: a server that runs your code in its own address space, where your code can crash the active worker process (which is usually handling multiple requests) for that server. Puma ordinarily runs ~eight worker processes, and a crash will kill one of them causing it to take the time to re-fork, and discard any other sessions that were also scheduled on that worker. Erlang runs a million worker processes, and one of them crashing doesn't cause anything big to happen at all.
- goldbrick 11y ago
  The web application server as such is a foreign concept to the PHP world. It's actually PHP-FPM that acts as the web application server in PHP's case. Incidentally, PHP only has the "shared-nothing" architecture partisans are so proud of talking up when you don't run it in PHP-FPM mode.

by jontro 11y ago

signa11 11y ago

> Also if an apache process dies it will not crash other requests can you have 2m Apache processes on your machine ?

jontro 11y ago
Well that would depend how long you run it for. They don't have to be simultaneous. It wouldnt make much sense to recycle the process for each request however. MaxConnectionsPerChild defines how often the process is recycled
- klibertp 11y ago
  > They don't have to be simultaneous. Now you're just moving a goalpost. We're talking about Erlang processes - you can have millions of them simultaneously. > It wouldnt make much sense to recycle the process for each request however. It does make a great deal of sense from the fault-tolerance perspective. It also helps security. I have an unpleasant feeling that you don't know much about Erlang and its philosophy. The "one process per connection" architecture has many benefits; it's a canonical way of getting concurrency and parallelism on Unix systems, for example. The problem is the way OSes handle and schedule processes, it simply doesn't work with a very large number of them. Erlang implements its own kind of processes, which enforce the same constraints os OS-level processes without taking megs of RAM each and without being pressed after spawning a few thousand processes.
  - jontro 11y ago
    What I'm saying is that it's misleading to call one process a web server when they really are saying "How we handle 2 million simultaneous web requests". Also I would be very interested in reading such a writeup. There are many different approaches to dealing with it (i.e. on thread per connection / one process / poll based approch). I certainly can see the benefits of having it in lightweight threads called processes in this context.
    - toolz 11y ago
      >it's misleading to call one process a web server How is that even slightly misleading? That's exactly what many web servers on erlang do.
    - klibertp 11y ago
      > What I'm saying is that it's misleading to call one process a web server when they really are saying [...] No. It's simply a terminology used in Erlang, there's nothing misleading in it, once you know the definition. I mean, there is very specific thing called "server" in Erlang: http://erlang.org/doc/man/gen_server.html http://erlang.org/doc/man/gen_server.html and also "processes" are described here: http://erlang.org/doc/reference_manual/processes.html http://erlang.org/doc/reference_manual/processes.html What's highly misleading is using more general definitions of such words instead of Erlang-specific meanings. This is a conversation about Erlang and it makes sense to use the terms accepted in Erlang; you can't blame anyone for the fact that some of these terms have meanings different than you'd expect.
      - Vendan 11y ago
        It's misleading because there are now 2 different definitions of the exact same word at work. It's a computer running a process running an Erlang VM that is then running multiple Erlang processes. It is completely reasonable to be annoyed at that. Many languages have a concept of threading in userspace rather then kernel space, but they don't just call it threading, they give it another name so that it can be distinguished from the existing concept. For example, stackless python's tasklets, Go's goroutines, green-threads.
- 59nadir 11y ago
  > Well that would depend how long you run it for. They don't have to be simultaneous. The long way of saying "No, I can't, but I really don't want to accept that there might be a better model for this than my out of the box Apache setup."
janvidar 11y ago
I suppose this depends on your machine.
- 59nadir 11y ago
  What if there was a model where it depended less heavily on your machine because of over 20 years of development with the goal of providing stable, robust systems aimed specifically at allowing you to run many things in parallel? What if the framework/API for it was developed for production systems from the beginning, meaning its API was made singularly for being able to easily spawn, manage and control these processes? The whole point of this article is that there is an architecture behind this and that this architecture is believed to be generally useful.
laumars 11y ago
Theoretically yes. Pragmatically no. There comes a point when it makes more sense to scale sideways (more OS instances) instead of up (more processes on beefier hardware). It's no secret that Apache isn't the leanest of HTTP daemons, but that's really a separate point to the argument of whether you can reasonably argue a process as a web server.

derefr 11y ago

Apache was a bad analogy. There is a thing that needs to be multi-process and fault-tolerant with the default case of badly-written code tossing out more state than just your own session, but it's not a web server that works like that. Instead, it's a "web application server", like Puma is for Rails apps: a server that runs your code in its own address space, where your code can crash the active worker process (which is usually handling multiple requests) for that server. Puma ordinarily runs ~eight worker processes, and a crash will kill one of them causing it to take the time to re-fork, and discard any other sessions that were also scheduled on that worker. Erlang runs a million worker processes, and one of them crashing doesn't cause anything big to happen at all.

goldbrick 11y ago
The web application server as such is a foreign concept to the PHP world. It's actually PHP-FPM that acts as the web application server in PHP's case. Incidentally, PHP only has the "shared-nothing" architecture partisans are so proud of talking up when you don't run it in PHP-FPM mode.