DSWEB

In this article, I’ll share our experience tackling two challenging issues on a server running CyberPanel and OpenLiteSpeed: slow WordPress admin panels and the inaccessibility of the OpenLiteSpeed WebAdmin interface on port 7080. This case study is designed to help server administrators, web developers, and WordPress site owners facing similar problems. We’ll walk through the entire process—from diagnosis to optimization—complete with all commands, explanations, and takeaways.

Initial Situation

On a server with CyberPanel, hosted on Digital Ocean (a droplet with 1 GB RAM and 8 CPUs), I noticed the following:

• WordPress admin panels were loading very slowly (up to 10–15 seconds).
• The OpenLiteSpeed WebAdmin (the server management interface) at http://[SERVER_IP]:7080 wouldn’t open in the browser.
• Server load was high: numerous PHP processes (lsphp), an average load (load average) exceeding 10 with 8 CPUs, and swap memory heavily utilized (400 MB out of 981 MB).

The domain [olddomain.com], previously used for WebAdmin, had been removed, and its Let’s Encrypt certificates had expired (since June 2022), causing issues with HTTPS access.

Step 1: Diagnosing WebAdmin OpenLiteSpeed Inaccessibility

The first issue was that the OpenLiteSpeed WebAdmin at http://[SERVER_IP]:7080 wasn’t accessible. I started with some basic checks.

Checking Port 7080

I ran the following command to see if port 7080 was listening:

ss -tuln | grep 7080

Result:

udp    UNCONN  0       0              0.0.0.0:7080         0.0.0.0:*            
tcp    LISTEN  0       4096           0.0.0.0:7080         0.0.0.0:*

The port was listening, meaning OpenLiteSpeed should theoretically be responding.

Testing with curl from the Server

I ran:

curl -v http://[SERVER_IP]:7080

Result:

* Connected to [SERVER_IP] ([SERVER_IP]) port 7080 (#0)
> GET / HTTP/1.1
> Host: [SERVER_IP]:7080
< HTTP/1.1 302 Found
< location: /login.php
< server: LiteSpeed

The WebAdmin was working and redirecting to /login.php, which is expected behavior. However, the page still wouldn’t load in the browser.

Checking WebAdmin Configuration

I noticed that the WebAdmin configuration file (/usr/local/lsws/admin/conf/admin_config.conf) had secure 1, forcing the server to redirect HTTP requests to HTTPS. But since the certificates for [olddomain.com] were expired, HTTPS (https://[SERVER_IP]:7080) wasn’t working.

I attempted to change secure 1 to secure 0 to disable HTTPS:

sed -i 's/secure 1/secure 0/' /usr/local/lsws/admin/conf/admin_config.conf
systemctl restart lsws

This didn’t work immediately due to a syntax issue with the sed command (e.g., extra spaces in the line). I manually edited the file:

nano /usr/local/lsws/admin/conf/admin_config.conf

I changed secure 1 to secure 0 and restarted OpenLiteSpeed:

systemctl restart lsws

Firewall Issues

After disabling HTTPS, I ran curl again from the server, and the WebAdmin responded correctly. However, from my local computer (Mac), the page still wouldn’t load:

curl -v http://[SERVER_IP]:7080
* connect to [SERVER_IP] port 7080 failed: Operation timed out

This pointed to an issue with external access. I checked the ufw firewall:

ufw status

Result: Status: inactive. I enabled ufw and added a rule:

ufw enable
ufw allow 7080/tcp
ufw allow 22/tcp  # To avoid losing SSH access
ufw reload

But this didn’t help. I realized the issue might lie with the CyberPanel firewall.

Configuring the CyberPanel Firewall

CyberPanel has its own firewall that overrides ufw. I logged into CyberPanel (https://[SERVER_IP]:8090), navigated to Security > Firewall, and added a rule:

• Protocol: TCP
• Port: 7080
• Action: Allow

I clicked Reload, and after that, the page http://[SERVER_IP]:7080 finally opened in the browser!

Step 2: Diagnosing Slow WordPress Admin Panels

With WebAdmin access restored, I moved on to the slow WordPress admin panels. I ran the top command to assess the server load:

top - 02:14:51 up 50 min,  2 users,  load average: 10.74, 9.72, 7.32
Tasks: 156 total,  17 running, 139 sleeping,   0 stopped,   0 zombie
%Cpu(s):  6.6 us, 24.3 sy, 67.1 ni,  0.0 id,  0.0 wa,  0.0 hi,  2.0 si,  0.0 st
MiB Mem :   1971.5 total,    136.0 free,   1178.2 used,    657.4 buff/cache
MiB Swap:    981.0 total,    580.2 free,    400.8 used.    208.1 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    766 mysql     20   0 1249868 185152   7184 S   6.0   9.2   2:31.40 mysqld
   5113 user1     21   1  288064 169700 104132 R   5.3   8.4   0:02.95 lsphp
   5125 user1     21   1  277740 158344 103012 R   5.3   7.8   0:02.44 lsphp
   5152 user2     21   1  348492 155904 104484 R   5.3   7.7   0:01.27 lsphp

• Load average of 10.74 (with 8 CPUs) — too high.
• 17 running lsphp processes, each using 5–8% CPU and 7–8% memory.
• Swap usage (400.8 MB) — this slows things down.

Step 3: Optimizing PHP Processes

I logged into the OpenLiteSpeed WebAdmin (http://[SERVER_IP]:7080) and reviewed the PHP settings:

• Configuration > Server > External App > lsphp.
• It had:
  • PHP_LSAPI_CHILDREN=10
  • LSAPI_AVOID_FORK=200M

Changes

• • Reduced the number of PHP processes:
    • Max Connections: From 10 to 8.
    • Environment:

PHP_LSAPI_CHILDREN=8

• • Increased the memory limit to avoid frequent restarts:
    • Environment:

LSAPI_AVOID_FORK=300M

• Limited memory usage:
  • Memory Soft Limit: 512M
  • Memory Hard Limit: 768M (reduced from 1024M to avoid swap usage).
• Saved and performed a Graceful Restart.

Step 4: Enabling and Configuring OPcache

I created a phpinfo.php file to check the OPcache status:

• • In /home/[example.com]/public_html:

echo '<?php phpinfo();' > phpinfo.php

Initially, I encountered an error:

Parse error: syntax error, unexpected '' > phpinfo.php' (T_ENCAPSED_AND_WHITESPACE), expecting end of file in /home/[example.com]/public_html/phpinfo.php on line 1

This was due to extra characters in the file. I edited the file using Sublime Text (via FileZilla), leaving only:

<?php phpinfo();

After that, the page https://[example.com]/phpinfo.php loaded, and I saw:

• PHP Version 7.4.33.
• OPcache enabled: opcache.enable = On.

I optimized the OPcache settings in the file /usr/local/lsws/lsphp74/etc/php.ini:

[opcache]
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.file_cache_consistency_checks=0

Restarted OpenLiteSpeed:

systemctl restart lsws

Step 5: Configuring LiteSpeed Cache

I logged into the WordPress admin panel (https://[example.com]/wp-admin) and configured the LiteSpeed Cache plugin:

• LiteSpeed Cache > Cache:
  • Enable Cache: Yes.
  • Default Public Cache TTL: Changed from 604800 seconds (7 days) to 43200 seconds (12 hours).
• LiteSpeed Cache > Object:
  • Object Cache: Yes (used Memcached, which was active on the server).
• LiteSpeed Cache > Optimize:
  • Enabled CSS Minify, JS Minify, HTML Minify.
• Cleared the cache: Purge All.

Step 6: WebAdmin Becomes Inaccessible Again

After optimization, the page http://[SERVER_IP]:7080 became inaccessible again. I ran curl from the server:

* Connected to [SERVER_IP] ([SERVER_IP]) port 7080 (#0)
> GET / HTTP/1.1
< HTTP/1.1 302 Found
< location: /login.php

The WebAdmin was working, but I couldn’t access it from my local computer. I rechecked the CyberPanel Firewall, iptables, ufw, and Digital Ocean Firewall. It turned out that after a reboot, CyberPanel had reset the rules. I added port 7080 again and ensured it stayed allowed.

Results

• Admin Panels and Sites: After reducing the number of PHP processes, enabling OPcache, and configuring LiteSpeed Cache, the admin panel load time improved dramatically (from 10–15 seconds to 1–2 seconds).
• Server Load: The average load dropped to 7–8, but swap was still in use. I recommended upgrading the server to 2 GB RAM.
• WebAdmin: Access to http://[SERVER_IP]:7080 was restored after reconfiguring the CyberPanel Firewall.

Conclusions and Recommendations

1. Diagnosis: Always check accessibility with curl and port status with ss.
2. Firewall: With CyberPanel, check not only ufw but also the built-in firewall.
3. PHP Processes: Limit the number of lsphp processes via PHP_LSAPI_CHILDREN (8 for 8 CPUs).
4. OPcache: Enabling and tuning OPcache significantly boosts PHP performance.
5. LiteSpeed Cache: Configuring caching (TTL, Object Cache) reduces server load.
6. Server Upgrade: For stable performance, I recommend 2 GB RAM to avoid swap usage.

I hope this case study helps you solve similar issues! If you have questions, feel free to leave a comment on. 😊