> forking 16 instances is going to be a lot heavier on memory
It really depends on how the application is designed. Fork operates through mmap and copy-on-write. It's extremely lightweight by default.
A well-designed fork-based application will already have everything necessary to run a given process into memory, not munge any of the existing shared memory, and only allocate and free memory associated with new events/connections/etc.
When programmed that way, individual forks are incredibly light on resources. All the workers are sharing the exact same core application code and logic in memory.
Yep, but that's simply how the linux kernel works [1]. As a programmer you need to essentially load up all your modules/libraries/data/etc that you will need into memory before the fork, and treat the forked() processes as read-only as much as possible from a resource perspective. If you modify anything from the parent, you get your own page as soon as that happens. [2][3]
It really depends on how the application is designed. Fork operates through mmap and copy-on-write. It's extremely lightweight by default.
A well-designed fork-based application will already have everything necessary to run a given process into memory, not munge any of the existing shared memory, and only allocate and free memory associated with new events/connections/etc.
When programmed that way, individual forks are incredibly light on resources. All the workers are sharing the exact same core application code and logic in memory.