New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I've been serving a default WordPress site, my own WP site and the phpinfo() page, I didn't want anything too DB heavy as that would become the bottleneck, not the webserver.
Honestly once it's configured it's not bad, it's just as fast or slightly faster than nginx+fpm it seems, however it does use a lot more resources. I see they're offering a free trial for the commercial product I'll probably give that a shot, I'm only interested in it because it works as a drop-in replacement on cPanel. However, most of the VPSes I manage are small and will probably benefit more from smart PHP caching.
@nunim I've tried the 15 day trial on one of our nodes and saw a considerable improvement with one of our customer's heavy Drupal sites. Now it's back on Apache 2.4 + MPM Event + FastCGI + Varnish Cache. Each node has 32GB RAM assigned to Varnish, so static content is served extremely fast. Customers also have the ability to control what's cached and the TTL for each account individually. I think that LiteSpeed is faster when working with PHP though.
Also @nunim, this slipped my mind: Nginx depends of PHP-FPM as an external daemon to process PHP requests. If Nginx had something better to work with, I'm sure PHP performance would be better. However IMHO there is no tight integration between PHP and Nginx. Just my 2 cents.
Aren't there other options? Personally I've always used PHP-FPM. I also use APC though there are a couple other options (eaccelerator and...X-something)
There are, like SpawnFCGI, with PHP-FPM being the best option for Nginx. I'm don't think SpawnFCGI is even maintained anymore. In order to speed things up an internal FastCGI module would be needed for Nginx, and also said module would need to be configurable and the scripts would need to be run as their respective owners (think SuExec). I don't see this ever happening with Nginx though.
FPM sucks ass at process management, which is supposed to be its 'core' principle. The only way you'll get stability out of it is by setting the PM to static, which defeats its entire purpose.
HHVM is recommended if living life on the edge is fine, or stick to php-cgi through either spawn fcgi -- or direct.
FastCGI by nature is external, you're looking for DSO. Litespeed's LSAPI is also so-so.
You CAN do privilege separation with both php-cgi, or FPM + nginx if you so desire, really. FPM can even chroot directly, while CGI can run as its own user within a chrooted environment. Run different nginx instances with different users, and tie it all back together with haproxy, or another nginx instance.
Not really hard, herp derp.
Zend optimizer is the recommended PHP object cache now, APC is what's being 'replaced.'
E-accelerator is EEOL, X-cache however does appear to be going strong.
That's how I'm using it.
Thanks for your advice.
Cleaned this up per OP's request.
If you have a 8 Core Server, you will be fine with $31/Month License but 2-CPU license for $46/Month? I did better go with Apache instead and will invest that money somewhere else.
I tried their free trial with caching and I didn't see much single site performance improvement over nginx or OpenLiteSpeed. I know that a single site is not their market as they're looking for me to use this on a shared box, however that's a harder environment to replicate in a test enviroment.
I'll be sticking with nginx for now on my personal boxes, however one thing I did notice is that Apache without a doubt takes longer to connect than either nginx or LiteSpeed, does anyone know why this is? I've tried all 3 mpms and they all have a longish initial connection period, and from the benchmarks I've done it seems like A2.4 is worse than 2.2 in many aspects, time to first byte being one of them.
I have noticed this as well, even on a first page load with Varnish in front of it. I would have said it's I/O access, however it does the same even when installed on a RAID 10 SSD array. Nginx on the other hand just pops up, and so does LiteSpeed. What are we missing?
Necroposting...
Man. Sorry I missed this, guys.
Let's see. There's a bunch to clarify...
Yes. The licenses are per core. No. You do not need to license all your cores. The license controls how many cores LSWS (LiteSpeed Web Server) has access. The rule of thumb is you'll need LSWS to have access to about a quarter of your cores. LSWS is fast and lightweight, so most of your server's heavy lifting is going to be other processes (like PHP). Those other processes still have access to all your cores. This wiki was referenced already, but it might help to put it out there again: http://www.litespeedtech.com/support/wiki/doku.php?id=litespeed_wiki:license:what_license_to_choose
I really liked the earlier post by @marcm thinking about our rationality in our pricing structure: We are a for-profit company and this has been working well for us. That doesn't mean we will definitely not change the structure. It's definitely a complicated licensing scheme. We might be interested in ways to simplify the scheme and make it easier to join. We are probably not slashing prices considerably, though. I'll explain in answer 3.
There are times when you need to scale, of course (awful MySQL queries, anyone?), but many, many people have used LSWS as an alternative to purchasing more hardware. If you're getting a lot of load because you're getting a lot of connections and Apache's creating a new process for each connection, well, LSWS is a much more efficient solution to that load problem than throwing more hardware at it. Most of our users use LSWS because it costs them significantly less than trying to throw hardware at their load problems. This is why we believe our prices are fair. In most cases, LSWS saves customers money.
I'm definitely happy to clarify or discuss anything. Sorry again for leaving y'all in the lurch. Thanks for thinking of me. I'll try to be better about being in touch.
m
It is definitely not 100% compatible.
There are http header cache control directives that either don't work like apache or just flat out won't work.
I'm using Unixy Varnish + Nginx, Way faster than litespeed and the billing cycle isn't monthly it's a quarter and it costs less than Litespeed
Varnish + Cpanel, Xcache, PHP ran as DSO, I can get over 1,500 reqs/s on a modestly configured 8GB, 4 core VPS. I honestly, don't see the need for litespeed. If a client can't handle that performance, there is always dedicated nginx to go faster.