Not to stop FCGI apps while reloading LSWS
 

Hello,

By using LSWS, I found that when I reload LSWS executing /opt/lsws/bin/lswsctrl reload makes my FCGI apps having to restart on the next request. As it takes some time to start my FCGI app (a RoR app), this delay is annoying after each reloading since I often must reload the config of LSWS to take the config changes in account. Is it possible to make reloading the config not to affect the FCGI app which are not concerned by the config changes ?

I am also wondering whether FCGI apps are running all the time waiting for requests or not ? For example if I have 10 vhosts witch each a FCGI app context for the URI "/", will the 10 apps be in memory waiting for visitors to request web pages ? Does LSWS do something to optimize memory usage with several (tens, hundreds or thousands...) vhosts with each his FCGI app, all stuff running on the same computer ?

Thank you in advance,
Best Regards,
Roman.

If you want that, you have to start FCGI application manually with a FCGI spawner.

LSWS will start FCGI apps on demand, but did not stop them when there is no request to process. Maybe we will add a feature to stop unused FCGI app. Some FCGI apps exit after handling certain number of requests.

LSWS did not do anything special in FCGI process management for mass hosting environment yet, but we will do if there is enough interest in using LiteSpeed in this kind of environment.

Right now, we recommend LSAPI over FCGI when possible, LSAPI has better process management in nature.

Ok, thank you for the useful answer 8).

I am interested in LSWS for a mass hosting environment (that's why I previously asked about FCGI apps stopping/starting).

Can you estimate a number of FCGI apps per an amount of memory as unit -- recommended to keep the server running well, please ?

it really hard to say, and it depends on how much memory a FCGI app uses and number of FCGI app required. Anyway, there should be at least 15-20% free memory for OS cache and file buffering, using swap memory should be avoid.

Thanks one more time, mistwang :D.