Notes: LiteSpeed Certification Part 2

Picking up from yesterday, you can find my notes here: LiteSpeed Certification Part 1.

Understanding OPCache

By enabling OPCache, you can speed up PHP that cannot be cached. As with anything, this comes with pros and cons:

  • Pro: PHP is served faster by caching internal calls
  • Con: OPCache is cleared when restarting server or PHP services; increased RAM requirements because of the increased demand of OPCache’s cache storage handling // Update: newer versions of LSWS (starting with LSWS 5.3) were updated so OPCache no longer gets cleared upon restart– PHP remains in a detached state and is unaffected from server restarts

To enable OPCache, you either install the EasyApache package or enable it in CloudLinux PHP Selector, and then add the appropriate ‘on’ directive within the active php.ini file. Documentation on this can be found here and here.

Optimizations: Per-user INI Files

Users can enable specific, PHP-related .ini files for a single domain, multiple users, or all users by doing one of the following:

  1. Creating a .conf file in the appropriate include path for a domain; (single or multiple users)
  2. Modifying the appropriate .user.ini file (all users)

More info on this here.

Setting PHP Versions Per-Directory

This can be done using EasyApache (cPanel & WHM) or an alt-php (CloudLinux) version. The following line would be added to the .htaccess file of the directory that you’d like the PHP version to be altered:

AddType application/x-httpd-ea-php70___lsphp .php .php7 .phtml

^In this example, PHP 7.0 would be utilized, regardless of what the global version is. More info here. As a note, Cloudlinux PHP selector works with Apache but does not work with LSWS.

Troubleshooting LSPHP

Common issues might include 503 errors, timeouts, max connection issues, and missing script handlers.

503 Errors

When these errors arise, check the following:

  1. LVE Settings (if applicable) to see if there are limitations or restrictions at play
  2. for a potential attack occurring on the site in question
  3. LSWS Documentation on troubleshooting 503 errors

If none of the above works, add the following to the External Application Environment Variables, which will allow your server to provide debugging info:

LSAPI_ALLOW_CORE_DUMP=1

^This will also create dumps of the crash to be created for further analyzing.

Timeouts

When frequent timeouts are occurring, try the following:

  1. Turning off Abort Globally or at the site level
  2. Timeout override, allowing scripts to run longer

Max Connections- “Resource Limit Reached”

High Traffic sites can sometimes reach a max connection limit and will be put in a WaitQ state. When this happens, users will need to wait to get out of the WaitQ state, leading to higher page loading times and eventually timeout. A temporary fix:

  1. WebAdmin Console > Configuration > Server > General > Apache Configuration, then change PHP SuExec Max Connections to a higher number than the WaitQ value

Missing Script Handlers

The following screenshot from a LSWS Interface may be interpreted as errors given the level column:

What’s actually happening here is that these entries do not have the version of PHP required and installed from EasyApache. These messages can be safely ignored, and they should go away when the users installs the correct PHP versions.

Cloudlinux Integration

Helpful doc here. Not sure how relevant this section will be to Reclaim given our use of Reclaim Cloud, but will work through the possibilities anyway.

Ruby Python Selector

  • included with Cloudlinux as up LSWS 5.2, and recommended to get that everything is running properly with Apache before attempting to work in a LSWS environment. Info on switching to LSWS here.

Node.JS Selector

  • Included with Cloudlinux in version LSWS 5.3; if it works on Apache you should be good to go. No extra install script necessary

Finally, resources for troubleshooting the Cloudlinux integration can be found here. This may involve making sure that suEXEC is enabled and perhaps increasing the amount of Max Connections to a number higher than the default 10. Note that the Max Connection setting should be less than or equal to EP limit to avoid 500 or 503 errors. Use the following equation to determine the correct Max Connection setting:

SuExec_MaxConn = CloudLinux EP / #CPU License

ModSec Integration Overview

Items of note for ModSecurity’s integration with LiteSpeed:

  1. Custom ModSecurity engine
  2. Good integration with vendors such as Imunify360 and LiteSpeedspecific rules
  3. Rules only execute for dynamic requests and not static (Performance boost)
  4. Does not support audit logging mode event-driven architecture

QUIC and HTTP/2

QUIC and HTTP/2 are enabled by default with LSWS.

To disable QUIC, learn more here. To disable HTTP/2 or HTTP/3 learn more here. Its recommended to keep them on globally and then disable on a per-account basis fir the speed improvements they give.

General Troubleshooting

.htaccess-related issues

As a good rule of thumb, LSWS generally supports all the same rewrite and .htaccess rules that Apache does. That said, LiteSpeed can be a bit more strict in some instances, or may behave differently in others. For example:

If there is garbage or spam text in .htaccess, Apache would through a 500 error whereas LiteSpeed will typically ignore it. Also, the L last tag on Apache will continue processing, whereas LiteSpeed reads this as the last rule to run, so it would stop processing the rules for the request.

If you ever want to run rules on LiteSpeed only, not Apache, you can use the following tags:

<IfModule litespeed>
#Rules Here
</IfModule>

Cloudflare

Cloudflare enabled + 522 errors may mean that LSWS Anti-DDOS settings are causing connections to be blocked. From there you’d want to whitelist IPs as needed in LiteSpeed’s Allowed List (Server>Security>Allowed List.) More info here.

CSF Integration issues

CSF/other firewalls can cause issues with accessing the WebAdmin Console area. Make sure port 7080 is open inside of TCP IN/OUT. More info about open firewall ports here.

Log Locations for Debugging

  1. Error log: /usr/local/apache/logs/error_log
  2. stderr.log: /usr/local/apache/logs/stderr.log
  3. Rewrite log: /usr/local/apache/logs/error_log
  4. PHP error log: error_log under user account document root

And with that, I’m certified!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top