UnixGuru uses LiteSpeed Enterprise WebServer on its Shared & Reseller Hosting
Upto 5 x faster than apache for static data, using 85% less memory.
Up to 40 x faster than apache for dynamic content.
LiteSpeed Web Server: Means Less Crowded Servers
LiteSpeed Web Server uses less CPU and memory than Apache and this usage stays predictable even with traffic spikes or DDoS attacks.
This means that, given the same hardware:-
- – LSWS can double or triple server capacity.
- – Extra capacity equals a less crowded, more stable server and more responsive websites for our customers.
LiteSpeed Web Server: Means Faster Sites
LiteSpeed Web Server handles connections faster and more efficiently. LiteSpeed’s exclusive server API, LSAPI, also gives you the fastest web applications and access to features — high-performance suEXEC and efficient opcode caching — that make an even bigger difference in shared hosting.
This means web apps like Magento (especially with LiteMage Cache) or WordPress run even faster on LSWS.
LiteSpeed Web Server: Means Better Stability
Thinking of upgrading to a VPS?
You may not need to. LiteSpeed Web Server’s predictable memory and CPU usage lead to better stability, as everyone on the server uses fewer resources and you worry less about being slowed down by a resource hungry neighbor.
Should your neighbor get too busy, CloudLinux will keep them under control.
LiteSpeed’s high-performance, secure suEXEC capabilities, and anti-DDoS features also mean consistent high speeds with less concern over security breaches.
LiteSpeed Web Server with CloudLinux = Fast, Stable & Secure
When these features are further combined with CloudLinux, the server becomes the most performant, stable & secure environment available for shared hosting.
PHP LSAPI suEXEC ProcessGroup
PHP LSAPI 6.4 introduced the new suEXEC ProcessGroup mode.
ProcessGroup allows shared hosting providers with extra memory to get better PHP performance through per-user opcode caching.
It also allows custom php.ini files, and thus CloudLinux’s PHP Selector.
What is suEXEC?
suEXEC makes PHP more secure by running each PHP process as the owner of a particular account and not as the web server user. This means that even if one user on a server is compromised, PHP scripts run from their account will not have access to other users’ files. suEXEC has long been a basic feature of shared hosting.
What is suEXEC ProcessGroup?
suEXEC ProcessGroup is set up similarly to PHP-FPM pools. ProcessGroup provisions a parent process for each ProcessGroup user. This parent process runs as the owner of the user’s document root and spawns new child processes when that user needs a PHP process. Forking child processes this way requires less overhead than creating brand new processes and these processes can share an opcode cache. ProcessGroup thus maintains the security of suEXEC, but spawns processes faster and allows for extremely effective per-user opcode caches.
Faster process generation
Forking child processes is faster than creating new processes because it has less overhead.
LiteSpeed’s most powerful suEXEC opcode caching
ProcessGroup allows for LiteSpeed’s most powerful suEXEC opcode caching. Opcode cache stores compiled PHP scripts and variables, allowing for faster PHP response. But opcode cache memory can only be shared among child processes forked off the same parent process and it is flushed if the parent process ends. In suEXEC Worker (LiteSpeed’s default suEXEC mode), all processes are standalone and opcode cache memory is flushed every time a PHP process ends. Because, in ProcessGroup, child processes are forked off a continuous parent process, each user’s cache is not flushed and their scripts can be used many times.
Custom php.ini files
Because each process group has its own parent process, this means PHP suEXEC ProcessGroup is compatible with custom php.ini files. A custom php.ini allows the use of CloudLinux’s PHP Selector.
A Detailed Discussion of Event-Driven vs. Process-Based Servers
LiteSpeed Web Server and Apache are built upon different architectures. Apache comes from an older breed of servers using process-based architecture. This means that Apache starts a new process (or thread) to handle every connection it gets. If you get more connections, Apache makes more processes. If a connection requires PHP, Apache starts up PHP inside its process. This is fine (and conceptually very simple), until you start getting more than a few connections. Starting a new process creates considerable overhead for the CPU. Thus, if you get more connections, your CPU (and memory) usage increases exponentially. That is when your server’s load begins to rise and users on your site decide it’s not worth it to wait for your pages.
The solution to this is event-driven architecture. Event-driven architecture means LiteSpeed Web Server handles all the connections it gets with one (or a few) processes. This one process stays open and handles all events that pop up — new requests coming in and new dynamic responses ready to go out. LiteSpeed Web Server concerns itself not with creating new processes to handle every aspect of every connection, but with reacting to events that occur.
For static content (like images, CSS, HTML), the advantage is obvious: instead of consuming the overhead required for a new process for each request, LSWS’s one process just handles the requests as they come in. This is much faster and consumes much less CPU and memory than Apache. For web applications (like PHP) and database processes (like MySQL), the interaction is a little more complex: LSWS fields requests and sends them along to external processes that create responses. LSWS does not wait around for these dynamic responses but instead gets to work fielding more requests (requests static content which it retrieves and requests for dynamic content which it forwards on) while the initial requests are getting processed. When a response is ready, LSWS gets a callback (a new event to react to) and knows to send that response back to the requesting client. In addition, LSAPI, LiteSpeed’s server API, keeps control over the number of processes that get created for web applications, reusing processes instead of creating new processes, further increasing CPU and memory efficiency.
Fielding all these requests and responses with one or a few processes is far more CPU and memory efficient than trying to create a separate process for each connection. When you get tens of thousands of concurrent connections, an event-driven server’s CPU and memory usage do rise, but not exponentially like Apache. This also allows for faster content delivery because the server skips the overhead of creating new processes and has more memory left for handling database and external applications. Most importantly, it allows for consistently low CPU (load) and memory usage, even during traffic spikes or DDoS attacks.
Anti-DDoS Features of LiteSpeed
LiteSpeed Web Server mitigates denial of service attacks
Because LSWS’s event-driven architecture handles all connections with a single process (or a few processes), LiteSpeed is able to easily gather data about the number of connections or amount of bandwidth an IP is using. This allows the server to efficiently impose limits.
Thread- or processed-based applications, like Apache, have trouble implementing features like this because they need to collect information from their many processes. By the time they know which IP to block, it’s too late.
LiteSpeed Web Server has a per-IP connection, request, and bandwidth throttling. With these customizable features, IPs that make too many connections or requests or ask for too much bandwidth will be blocked, stopping attackers before they overrun your server.
LiteSpeed Web Server handles much more traffic with far fewer resources, allowing it to survive larger attacks than less scalable solutions. This is especially important for very distributed attacks, where it is harder to isolate and block each attacker. Against such attacks, the best defense may be a scalable server.
SSL Renegotiation Protection
SSL renegotiation attacks can tie down a server by repeatedly renegotiating key material in an SSL connection. Because generating a key has substantial overhead for a server, this can allow smaller machines to take down large servers without enlisting a large network.
LiteSpeed Web Server’s SSL Renegotiation Protection caps the number of times a client can renegotiate SSL materials, closing this loophole.