LiteSpeed Web Server is Event-Driven 2018-01-15 15:44:49 LiteSpeed Web Server's event-driven architecture vs. Apache's process-based: Fewer processes means less overhead, more connections, and no hardware upgrade required.

Event-Driven vs. Process-Based Web Servers

Fewer processes means less overhead and more connections with no hardware upgrade required

The biggest difference between LiteSpeed Web Server and Apache comes down to architecture and the way that they handle connections: LiteSpeed Web Server is event-driven and Apache is process-based.

  • Apache creates a new process or thread for every connection. Creating these processes requires a lot of overhead.
  • LiteSpeed Web Server, with its event-driven architecture, serves all connections on a few processes, saving resources.
  • This efficient method of serving connections means you can serve many more connections, at a much higher rate, without upgrading your hardware.

Want to see it at work? Download a trial license or check out our customer testimonials and case studies.

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 My SQL), 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 for 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.

Coffee Making

Coffee Making - The Coffee Shop Analogy

Many people have compared these two approaches to different ways of running a coffee shop. In the process-driven approach, each employee serves one customer. They take the customer's order, fill it, and take payment. This is fine if you have a small number of customers or very simple orders like coffee and doughnuts. This does not work at Starbucks, where people are apt to order a "venti mocha two Splenda half soy half 2%" and are packing the house right before work. If each of your employees has to take orders, fill them, and take payment, you will need a lot of employees and a very, very big shop to keep people from being frustrated. This is how many hosts deal with more traffic: they just buy lots and lots of hardware. A more ideal solution, though, is to make your employees event-driven, the way Starbucks does — to have one person take the orders and others behind them filling the orders. The person taking the orders concerns herself only with relaying orders to the people on the backend. In this way, one person can do the work of many and you don't need a whole lot of extra counter space for many people taking orders. This solution scales much better and you save money on retail space and wages. LiteSpeed Web Server saves you money on hardware and support by requiring less CPU and memory and making your servers run more smoothly.

Accelerate your internet now.