5 ms·

Memory leaks on the server side are also a consequence of long-running single-process server software. What was traditionally run as a CGI (eg. Apache creating

Memory leaks on the server side are also a consequence of long-running single-process server software. What was traditionally run as a CGI (eg. Apache creating a fresh process for each request) or was started from inetd is now frequently implemented in a multi-threaded or evented fashion, so that using the O/S as garbage collector for memory and temp files doesn't work anymore. Not only does this put additional strain on getting memory management 100% right, it also creates memory fragmentation when done naively. While the consensus and narrative seems to be that evented I/O is more performant because the O/S doesn't have to schedule loads that have "nothing to do anyway most of the time" so to speak, I've yet to see a benchmark comparing traditional process-per-request vs. multithreaded and/or evented approaches; it's not that user-space memory management doesn't introduce additional overhead. My suspicion is that in many cases memory management strategies of desktop software have been used for server-side software without evaluation, or out of a habit because Java introduced GC into server software. But OTOH even OpenBSDs "new" (3-5 years old) httpd integrates traditional CGIs via the so-called "slowcgi" bridge, and uses evented I/O and asynchronous APIs natively so maybe I'm wrong on this one. If even OpenBSD developers themselves don't use ASLR and other techniques of OpenBSD to ensure non-deterministic memory allocation and go to great length to get equivalent protection within single-process request processing containers, they sure must be on to something.

algesten 10y ago
> Memory leaks on the server side are also a consequence of long-running single-process server software. On a tangent to this. I noticed that one benefit my company reaped from embracing a micro service architecture was that we get away with _a lot_ of shit code. Suddenly a NodeJS process can have glaring memory leaks and work fine for weeks because whenever it crashes, it restarts in 0.5 second and no one even bothered to investigate. Compare that with the good-ol-JBoss monolith with a 3-4 minute startup time. On the one hand, crap code can go unnoticed for weeks, which feels wrong and probably will bite us somewhere in the end, on the other hand, we can focus on function not code quality.
- koolba 10y ago
  Plus if you build for this from the get go and assign a max life to your processes with auto restart, it becomes a native part of of their lifecycle. With multiple processes listening to the same socket it's easy to create a continuously on service that under the covers respawns with no apparent loss of service.
- roguecoder 10y ago
  This is the Google approach to scaling to thousands of developers: build rock-solid infrastructure so none of the code can go too badly, and you can worry a lot less about the quality of most of the code. For most functionality, writing amazing code would just be wasted effort when a less-amazing developer could have implemented something good enough.

algesten 10y ago

> Memory leaks on the server side are also a consequence of long-running single-process server software. On a tangent to this. I noticed that one benefit my company reaped from embracing a micro service architecture was that we get away with _a lot_ of shit code. Suddenly a NodeJS process can have glaring memory leaks and work fine for weeks because whenever it crashes, it restarts in 0.5 second and no one even bothered to investigate. Compare that with the good-ol-JBoss monolith with a 3-4 minute startup time. On the one hand, crap code can go unnoticed for weeks, which feels wrong and probably will bite us somewhere in the end, on the other hand, we can focus on function not code quality.

koolba 10y ago
Plus if you build for this from the get go and assign a max life to your processes with auto restart, it becomes a native part of of their lifecycle. With multiple processes listening to the same socket it's easy to create a continuously on service that under the covers respawns with no apparent loss of service.
roguecoder 10y ago
This is the Google approach to scaling to thousands of developers: build rock-solid infrastructure so none of the code can go too badly, and you can worry a lot less about the quality of most of the code. For most functionality, writing amazing code would just be wasted effort when a less-amazing developer could have implemented something good enough.