Hello,
We are looking to replace apache with litespeed. Now we are in testing litespeed for compatibility with our setup.
Unfortunately we face some incompatibility which I think will not be very hard to be implemented.
First let me explain our setup:
CP: virtualmin (with little modifications in the code!)
Every account have premade structure for the main and additional domains (default for virtualmin working by default with apache +fcgid) and every website have it's own php.ini file
Structure is the following:
Apache 2.4 with mod_lsapi (CL module - but without cloudlinux installed slightly modified)
It is set up with one parent lsphp process per domain with limited max number of lsphp to fork and accepting per vhost SetEnv PHPRC /home/user/etc/php.ini (for main domain vhosts) and /home/user/domains/domain1.tld/etc/php.ini (for every additional website).
That way every domain have it's own php.ini/opcache and we do not need to set different opcache limit for different plans but set it for a website. Otherwise setting too high or to low the opcache memory limit will be unfair!
Also this php.ini is loaded after all default *.ini files. That way users are limited enough of the changes they can make in their php.ini files.
Changing PHP version per website is done by virtualmin changing the handler in the domains vhost.
As I see the most close to our setup is ProcessGroup Mode with one exception it use one parent lsphp for user(account) which interfere with our setup on three places
- custom php.ini for every website
- opcache limits for every website
- process limits for a website
The only difference I can see in our setup and the ProcessGroup mode of litespeed is the name of the socket file.
litespeed in process group mode - APVH_{username}_Suphp{phpversion number}.sock
our setup - lsapi_{handler}_UID_domain.tld.sock example lsapi_application-x-lsphp7.3_3521_domain-name.tld.sock
It will be great if we have an option to choose to have it like it is now or parent lsphp process per website!
We are looking to replace apache with litespeed. Now we are in testing litespeed for compatibility with our setup.
Unfortunately we face some incompatibility which I think will not be very hard to be implemented.
First let me explain our setup:
CP: virtualmin (with little modifications in the code!)
Every account have premade structure for the main and additional domains (default for virtualmin working by default with apache +fcgid) and every website have it's own php.ini file
Structure is the following:
Code:
/home/user/
\_public_html(for main domain)
\_etc/php.ini
\_domains
\_domain1.tld/
\_etc/php.ini
\_public_html
\_domain2.tld/
\_etc/php.ini
\_public_html
It is set up with one parent lsphp process per domain with limited max number of lsphp to fork and accepting per vhost SetEnv PHPRC /home/user/etc/php.ini (for main domain vhosts) and /home/user/domains/domain1.tld/etc/php.ini (for every additional website).
That way every domain have it's own php.ini/opcache and we do not need to set different opcache limit for different plans but set it for a website. Otherwise setting too high or to low the opcache memory limit will be unfair!
Also this php.ini is loaded after all default *.ini files. That way users are limited enough of the changes they can make in their php.ini files.
Changing PHP version per website is done by virtualmin changing the handler in the domains vhost.
As I see the most close to our setup is ProcessGroup Mode with one exception it use one parent lsphp for user(account) which interfere with our setup on three places
- custom php.ini for every website
- opcache limits for every website
- process limits for a website
The only difference I can see in our setup and the ProcessGroup mode of litespeed is the name of the socket file.
litespeed in process group mode - APVH_{username}_Suphp{phpversion number}.sock
our setup - lsapi_{handler}_UID_domain.tld.sock example lsapi_application-x-lsphp7.3_3521_domain-name.tld.sock
It will be great if we have an option to choose to have it like it is now or parent lsphp process per website!
Last edited: