4 ms·

Many small programs simply doesn't scale to the modern web when just the baggage associated with spinning up processes will kill you at any reasonable load. UNI

by sfifs 8y ago

Many small programs simply doesn't scale to the modern web when just the baggage associated with spinning up processes will kill you at any reasonable load. UNIX has nice ideas but recognise they were founded in the shared computer between a few dozen users environment of the 70s, not a web server serving thousands of requests a second of today

tonyarkles 8y ago
Isn't this basically what "serverless" is?
- sedachv 8y ago
  Great observation. And in fact "serverless" is the way that Unix network servers used to work: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd CGI is also the way the web used to work. Spawning processes has only gotten faster since then. The entire "process spawning doesn't scale to the modern web" argument is completely and totally bogus. Today, spawning a process in Linux is only 10-20 microseconds slower than creating a thread: http://www.bitsnbites.eu/benchmarking-os-primitives/ http://www.bitsnbites.eu/benchmarking-os-primitives/ The performance problems are elsewhere.
  - sfifs 8y ago
    What you are missing here is the fact that I/O is orders of magnitude slower than processor. Most of the time in servers is spent waiting for I/O and multiplexing green threads on processes without context switches while some execution paths are waiting on I/O gives you far higher capacity on the same hardware. See the other comment thread on GP comment.
- sfifs 8y ago
  serverless is primarily a decentralisation/small-scale/unpredictable workloads play where you trade off fixed costs of managing a dedicated instance for higher variable per call cost. At any reasonable scale and predictability, running a dedicated server is cheaper. The folks who started at a small scale in serverless but see traffic growing and kind of are in the middle space before jumping to dedicated servers have an entire art form of keeping their functions "hot" since both Lambda and AppEngine actually keep your functions hot loaded when once it's spun up for some time. https://www.google.com.sg/search?q=serverless+warm+up&oq=serverless+warm+up https://www.google.com.sg/search?q=serverless+warm+up&oq=ser...
bitofhope 8y ago
What do you mean by modern web? I don't see how modernity implies more load, at least for fork() bottlenecked programs specifically. If you're serving thousands of requests per second, you probably need a pretty beefy server anyway, regardless of the stack you're running. Forking makes good use of multiprocessor capabilities if nothing else.
- laumars 8y ago
  No, it really doesn't. Forking is expensive. Running a multithreaded (even if it's green threads rather than OS threads) http server and web application makes far better use of multi-processor capabilities. Shell scripting is a handy tool but it is also slow so you wouldn't write hot paths in shell scripts. And for the same reasons you wouldn't write busy web servers in CGI. Both are fork() heavy.
- sfifs 8y ago
  Modern language runtimes used in the server space like Go basically multiplex green threads across processes to minimize context switches between concurrent execution paths. By leveraging the fact that I/O is much slower than processor ops and switching green threads on I/O without necessarily always switching OS process, they easily scale to hundreds of thousands of concurrent requests. I don't really know about Erlang's model but it also has green threads. There's a reason why high traffic sites use languages like these. https://talks.golang.org/2012/concurrency.slide#1 https://talks.golang.org/2012/concurrency.slide#1

by sfifs 8y ago

tonyarkles 8y ago

Isn't this basically what "serverless" is?

sedachv 8y ago
Great observation. And in fact "serverless" is the way that Unix network servers used to work: https://en.wikipedia.org/wiki/Inetd https://en.wikipedia.org/wiki/Inetd CGI is also the way the web used to work. Spawning processes has only gotten faster since then. The entire "process spawning doesn't scale to the modern web" argument is completely and totally bogus. Today, spawning a process in Linux is only 10-20 microseconds slower than creating a thread: http://www.bitsnbites.eu/benchmarking-os-primitives/ http://www.bitsnbites.eu/benchmarking-os-primitives/ The performance problems are elsewhere.
- sfifs 8y ago
  What you are missing here is the fact that I/O is orders of magnitude slower than processor. Most of the time in servers is spent waiting for I/O and multiplexing green threads on processes without context switches while some execution paths are waiting on I/O gives you far higher capacity on the same hardware. See the other comment thread on GP comment.
sfifs 8y ago
serverless is primarily a decentralisation/small-scale/unpredictable workloads play where you trade off fixed costs of managing a dedicated instance for higher variable per call cost. At any reasonable scale and predictability, running a dedicated server is cheaper. The folks who started at a small scale in serverless but see traffic growing and kind of are in the middle space before jumping to dedicated servers have an entire art form of keeping their functions "hot" since both Lambda and AppEngine actually keep your functions hot loaded when once it's spun up for some time. https://www.google.com.sg/search?q=serverless+warm+up&oq=serverless+warm+up https://www.google.com.sg/search?q=serverless+warm+up&oq=ser...

bitofhope 8y ago

What do you mean by modern web? I don't see how modernity implies more load, at least for fork() bottlenecked programs specifically. If you're serving thousands of requests per second, you probably need a pretty beefy server anyway, regardless of the stack you're running. Forking makes good use of multiprocessor capabilities if nothing else.

laumars 8y ago
No, it really doesn't. Forking is expensive. Running a multithreaded (even if it's green threads rather than OS threads) http server and web application makes far better use of multi-processor capabilities. Shell scripting is a handy tool but it is also slow so you wouldn't write hot paths in shell scripts. And for the same reasons you wouldn't write busy web servers in CGI. Both are fork() heavy.
sfifs 8y ago
Modern language runtimes used in the server space like Go basically multiplex green threads across processes to minimize context switches between concurrent execution paths. By leveraging the fact that I/O is much slower than processor ops and switching green threads on I/O without necessarily always switching OS process, they easily scale to hundreds of thousands of concurrent requests. I don't really know about Erlang's model but it also has green threads. There's a reason why high traffic sites use languages like these. https://talks.golang.org/2012/concurrency.slide#1 https://talks.golang.org/2012/concurrency.slide#1