Exactly my situation. Thanks @mlunar@lemmy.world. The only way this could be done better was to do it in PHP / have fastcgi so it wouldn’t require a constantly running background process specifically for it.
Exactly my situation. Thanks @mlunar@lemmy.world. The only way this could be done better was to do it in PHP / have fastcgi so it wouldn’t require a constantly running background process specifically for it.
mlunar@lemmy.world 5 days ago
I don’t know a lot about fastcgi, but looking it up it seems like it also keeps a persistent process running to avoid execution overhead, but I don’t know how that process is managed 🤷♂️
Either way, you could use a supervisor of sorts that shuts down the process/container after some idle time (at least for containers I know some exist) and that should probably work fine (outside of interrupting scanning operations).
I haven’t tried it myself yet though :)
TCB13@lemmy.world 4 days ago
More of less, the good thing about PHP + fastcgi is that it keeps a configure amount of minimum persistent processes (plus a dynamic number) to avoid execution overhead like you said… now there’s an important detail, PHP processes are generic, meaning if you’ve 50 apps hosted in your server they can all be served with just one persistent process. No need to spin up 50 processes for each app like with node/go etc.
mlunar@lemmy.world 4 days ago
Thanks for the explanation, makes sense! This app relies quite heavily on in-memory caches, so it’s somewhat incompatible with that model :)
That said, I wonder if the startup time would be noticeable. Depends a lot on the configuration, but it shouldn’t take more than a few 100ms (esp. if you use skip_collection_counts).
TCB13@lemmy.world 4 days ago
Not really incompatible, PHP provides configurable shared memory across processes that survive even if fastcgi releases every process and just keeps something idle for new requests.