OpenLiteSpeed is a good choice: Page 2 - Enhance Control Panel

OpenLiteSpeed is a good choice

pratik_asabe

DracoBlue I was using OLS before enhance, on directadmin, and on runcloud before that, so i can say with confidence that i agree with you OLS has proven itself far far better option than Apache, in terms of speed, performance and resource utilization! It handles requests in a superior manner and i even once used apache with lsphp on directadmin via cloudlinux's mod_lsapi and that worked somewhat great too, not like native OLS with lsphp but superior performance than php-fpm.

Im now waiting for the persistent config update from enhance.

mike

We are using Nginx and found it better than OLS without caching .... its much more stable.

The issue with nginx on enhance is you cannot modify the config as you want 😏

twest

sikmo I have to use ELS because I need access to the config. OLS is limited to the default config, for example only 1 worker. Our servers are dedis 50cpu/250gb ram, if we used OLS on it we wouldn't be able to use half our system resources due to LS worker limitation. We run the 3-worker ELS and it runs smooth, the workers aren't being overloaded.

When OLS can have persistent config, then it will be suitable for larger servers. As it is, it's only good for smaller servers - otherwise it will be the bottleneck as the 1 worker is limited to how much data it can process.

The worker setting is only part of it. We optimize the rest of the config on ELS to account for the larger server size too. OLS config currently cannot be optimized for large servers.

twest

lefteris the biggest difference isn't a setting, it's the PHP processor. Apache uses php-fpm, while ELS/OLS use LSPHP. LSPHP hass much better efficiency.

Besides efficiency, LSPHP also does not need a custom config on per-website basis... With Apache on php-fpm, we had to optimize php-fpm for every website/package, as small packages need smaller php-fpm config than large packages that have more CPU/ram... With LSPHP we don't need to do that, LSPHP is good 1 config for all size packages.

lefteris

twest You mean the default lsapi config that is shipped with enhance/els installation?
or you modify it yourself?

Copernic

Browsing the CPFence blog, I found this article: How to Optimize OpenLiteSpeed for Large Shared Hosting Servers

Enjoy reading

twest

Copernic optimizing OLS would be fine if we had a persistent config. As it is, there's no persistent config. So if you go optimizing OLS now, prepare to watch your config get deleted at some point. I don't remember what Adam said specifically about it, I think he said something about the config getting wiped during any vhost changes, or whenever OLS is restarted (like when a htaccess file is updated)... So you could be needing to optimize your config multiple times a day every day lol

mike

Our 1 time experience with OLS:

Never used ELS but with OLS same server we had 1 woo site on it only and got gateway timeouts. switched to nginx everything is stable with no timeouts.

josedieguez

mike maybe you had left-over config or files from nginx, that error i have seen it with nginx, never with ELS or OLS..

cPFence

mike

Is this a high traffic site? If it is, try increasing the External App settings from the default 10 to 30 or higher.

Server Configuration > External App > LiteSpeed SAPI App > Max Connections = 30
Server Configuration > External App > LiteSpeed SAPI App > Environment > PHP_LSAPI_CHILDREN=30

OLS is a great web server, you should definitely give it another try.

Machiel92

Well, I've tried openlitespeed but didn't find it perfect. but what is perfect? For me nginx is still the way to go. fastcgi caching makes the sites quick and works good 🙂

I find OLS without caching no way quicker than nginx without caching.

JohnB

Machiel92 Correct. OLS / Litespeed correctly configured is not actually faster than Nginx correctly configured (which we can't do in Enhance yet). It wins in benchmarks because they use default settings. There are benchmarks where they basically have double the threads because of differences between default configs and then say "as we can see litespeed can handle twice the traffic..."

In the real world Nginx will almost always win on uncachable pages / requests which is where visitors feel a difference: checkout pages, dynamic content, search.

Cachable pages should be served via a CDN anyway...

From purely a memory/CPU usage standpoint, litespeed probably wins.

Darkle

I hear this all the time, and I think we all know and are aware of it (Nginx is faster than OLS without cache), but who really cares? I mean, who in their right mind is interested in benchmarks without cache?

Caching isn't just about speed, it's truly a matter of scalability and resource saving, which directly translates to saving money.

I'm not a fanboy like many who rave about LS. If tomorrow Nginx cache is better, I'll switch to Nginx. If it's Caddy, then I'll go with Caddy... it doesn't matter to me. But the fact is that LS cache (in most scenarios, especially WP) is considerably better, more powerful, and extensible.

JohnB In the real world Nginx will almost always win on uncachable pages / requests which is where visitors feel a difference: checkout pages, dynamic content, search.

That's exactly where you're mistaken with LS, you'll achieve cache:hit on dynamic pages, and you can do pretty complex things with ESI.

« Previous Page