status page of <module>mod_status</module> shows how many connections are
in the mentioned states.</p>
- <p>The improved connection handling does not yet work for certain
- connection filters, in particular SSL. For SSL connections, this MPM will
- fall back to the behaviour of the <module>worker</module> MPM and
- reserve one worker thread per connection.</p>
+ <p>The improved connection handling may not work for certain connection
+ filters that have declared themselves as incompatible with event. In these
+ cases, this MPM will fall back to the behaviour of the
+ <module>worker</module> MPM and reserve one worker thread per connection.
+ All modules shipped with the server are compatible with the event MPM.</p>
<p>The MPM assumes that the underlying <code>apr_pollset</code>
implementation is reasonably threadsafe. This enables the MPM to
<usage>
<p>The event MPM handles some connections in an asynchronous way, where
request worker threads are only allocated for short periods of time as
- needed, and other (mostly SSL) connections with one request worker thread
- reserved per connection. This can lead to situations where all workers are
- tied up and no worker thread is available to handle new work on established
- async connections.</p>
+ needed, and other connections with one request worker thread reserved per
+ connection. This can lead to situations where all workers are tied up and
+ no worker thread is available to handle new work on established async
+ connections.</p>
<p>To mitigate this problem, the event MPM does two things: Firstly, it
limits the number of connections accepted per process, depending on the