If I have cloudlinux set to 3 entry processes, and suexec max connections set to 5. The behaviour I would expect is for litespeed to return a 508 error to the client once the 4th concurrent process is requested. If I fork 20 HTTP requests to a user configured in this fashion, the result is basically this: 2014-07-10 04:31:52.476 [INFO] [APVH_cruvcom_Suphp:] PID: 783281, add child process pid: 784738, procinfo: 0x1739b90 2014-07-10 04:31:52.572 [INFO] [APVH_cruvcom_Suphp:] PID: 783281, add child process pid: 784739, procinfo: 0x183ee00 2014-07-10 04:31:52.680 [INFO] [APVH_cruvcom_Suphp:] PID: 783281, add child process pid: 784740, procinfo: 0x17c2f80 2014-07-10 04:31:52.787 [ERROR] [APVH_cruvcom_Suphp:]: Failed to start one instance. Resouce limit reached! 2014-07-10 04:31:52.787 [NOTICE] [idle] LVE limit is reached, reduce max connections to: 3. 2014-07-10 04:31:52.787 [INFO] Pid: 784741 does not associate with any external app 2014-07-10 04:32:04.083 [NOTICE] [APVH_cruvcom_Suphp:] Increase effective max connections to 4. 2014-07-10 04:32:04.086 [ERROR] [APVH_cruvcom_Suphp:]: Failed to start one instance. Resouce limit reached! 2014-07-10 04:32:04.086 [INFO] Pid: 784742 does not associate with any external app So it creates the 3 suexec processes, but then fails to create the 4th. This makes sense since the entry processes are set to 3. So cloudlinux is preventing litespeed from making the 4th. What litespeed basically does, is it appears to attempt to move some of these requests to the existing suphp processes. Basically the first 9 requests all get handled by litespeed, in that it queues each suphp process "3 deep" worth of HTTP requests. The remaining 11 requests just simply time out in the client. The remaining 11 also don't appear to get logged in any way. What is the configuration, if any, that would allow me to change the number of processes that will be queued to suphp/lsapi, (ideally so none queue beyond the initial), and that every request which cannot create it's own suphp child process will result in appropriate 500 error? There are a few topics in various forums (including this one), which suggest this situation should result in a 508 error.