Event-Driven Architecture
OpenLiteSpeed does not create one heavy process per connection. Instead, it uses an event loop that watches many connections and reacts when each one is ready for work.
The core idea
Most web connections spend much of their life waiting. Browsers wait for TLS negotiation, users wait between clicks, and clients often keep connections open for a short period in case more assets are needed. A process-per-connection design can waste memory on all of that waiting.
An event-driven server avoids that waste by keeping track of many connections and only doing work when a connection becomes active.
A mental model that helps
Imagine a restaurant with one waiter assigned permanently to each table, even when the table is just sitting quietly. That is wasteful. An event-driven model is more like a small team of efficient waiters responding whenever any table actually needs something.
That analogy is imperfect, but it explains why event-driven servers can stay responsive with far fewer active workers.
Why this helps
- Idle keep-alive connections consume less overhead
- Fewer workers can manage higher concurrency
- Memory usage stays more predictable under load
Why this matters for administrators
This architecture affects how you think about performance tuning:
- concurrency is not only about CPU count
- connection settings matter a lot
- keep-alive behavior can be efficient instead of automatically expensive
- memory pressure often shifts toward PHP, cache, or application layers rather than the web listener itself
Where the limits still appear
Event-driven architecture is not magic. You still hit limits when:
- PHP workers are saturated
- the database is slow
- storage is overloaded
- TLS handshakes spike CPU usage
- too many expensive dynamic requests bypass cache
So the event loop helps the web server itself, but it does not eliminate downstream bottlenecks.
Comparison with older models
| Model | Behavior under many idle connections |
|---|---|
| Process or thread heavy | Can consume more memory per client |
| Event-driven | Handles waiting connections more efficiently |
Why this pairs well with modern web traffic
Modern websites often cause a burst of many small requests for HTML, CSS, JavaScript, fonts, images, and API calls. OpenLiteSpeed's architecture is well suited to that pattern because it can keep many connections alive without dedicating a large heavyweight execution unit to each one.
Real-world effect
This is one reason OpenLiteSpeed often performs well on modest VPS instances. It can handle many concurrent clients without needing a huge number of heavyweight worker processes.
What you should remember later
When you troubleshoot performance, ask two separate questions:
- is OpenLiteSpeed itself overloaded?
- or is OpenLiteSpeed waiting on PHP, cache, storage, or database work?
That distinction is central to good diagnosis.
Operational meaning
This design is one reason OpenLiteSpeed performs well on small servers while still scaling to busy traffic patterns.