linux - Apache Server Slots, Memory, KeepAlive, PHP and SSL - how to speed up -

on debian web server (vps) cpu, 6 gb ram, , fast backbone internet connection, run php application. php runs in "prefork" mode (incl. apc opcache), because whenever search php , mpm worker, there abundant warning regarding thread safety. php application quite large, each server process requires 20 30 mb ram. there sensible data processed application, therefore, connections apache server ssl encrypted.

typically, application shows no or few images (about 1-3 files incl css , js per request) , users send new request each 1 minute (30 sec. 4 minutes, depeding on user).

recently, application faced big storm of user requests (that planned, no dos, 2.500 concurrent users). while cpu did fine (<50% use), server ran out of slots. point - in prefork mode - each slot requires memory , 6 gb enough "maxclients" 200 slots).

problem 1: according apache server-status, slots occupied "..reading..". reading 10 seconds , more, while php processing takes 0.1 2 seconds. few data sent users, guess ssl handshake. this, of course, occupies lots of slots (i enabled , configured mod_reqtimeout drop slow clients , - according http://unhandledexpression.com/2013/01/25/5-easy-tips-to-accelerate-ssl/ - used sslhonorcipherorder use faster encryption ciphers, sslcertificatechainfile transmitted).

problem 2: if enable keepalive (only 1 or 2 seconds) reduce ssl overhead, slots kept open and, therefore, occupied twice long, php processing require.

problem 3: if wanted serve 2.500 users, and want use keepalive speed ssl, require 2.500 slots. however, won't have machine 32 gb ram.

with enough users on server, test limits, stuck 110 requests per second, 50% cpu load on quadcore system (max. 400%). less req/sec if (re-)enabled keepalive. 110 req/sec on modern webserver - seems ridiculous! cannot believe apache, php , ssl can perform.

is there major fail in thinking? encounter basic limitation of prefork mode? did ignore obvious? ssl acutually such performance-eater? hints!

i'm author of article ssl performance. don't think handshake responsible 8+ seconds on reads. can useful information using http://www.webpagetest.org/ . handshake done when request marked "connected".

my guess slow processing of php app lot of concurrent users can make users wait lot more.

here ideas better performance:

• i don't think keepalive idea if each client request every minute.
• you enable ssl session tickets reduce handshake overhead.
• mpm-worker works fine lot of different setups, encourage try out.
• caching not if clients recieve different response every time.
• you should test php-fpm, speed php code.
• also, test apc, cache precompiled php code.
• i don't know architecture of app, defer sending results: data client, send immediate answer ("processing data..." or that), process data in background process, on next request, send calculated answer.