Difference between revisions of "Talk:278: Black Hat Support"
| Line 4: | Line 4: | ||
:You are correct and I have modified the explanation. It could also be due to a loop polling a socket that will never be freed(a deadlock), this was my interpretation. [[Special:Contributions/108.162.246.117|108.162.246.117]] 07:05, 1 November 2013 (UTC) | :You are correct and I have modified the explanation. It could also be due to a loop polling a socket that will never be freed(a deadlock), this was my interpretation. [[Special:Contributions/108.162.246.117|108.162.246.117]] 07:05, 1 November 2013 (UTC) | ||
| + | |||
| + | The explanations above don't seem to match "the load climbing out of control". The load typically means the CPU load, not latency. If the server is stuck on reading from a socket, the latency will grow but the load will plunge, since it's _waiting_ and thus not consuming the CPU cycles. Two typical problems connected with select() are: (1) As the number of sockets polled grows, the overhead of select() grows, so it uses more and more CPU just to go through all the sockets and check them all for readiness. (2) If some socket reports readiness through select() and then the program does not handle that readiness but keeps including this socket into the following select() calls, it will be stuck in a tight loop retrying select() and using all the available CPU of one processor. A less extreme variety of this case is the program being notified of multiple sockets being ready but handling only one socket before repeating select(). In this case the program will continue making progress but with the increased overhead of the unnecessary select() calls. [[Special:Contributions/108.162.246.5|108.162.246.5]] 21:07, 30 January 2014 (UTC) | ||
Revision as of 21:07, 30 January 2014
select() calls are used to poll sockets for activity (read, write and exceptions), and I suspect the issue was that the timeout value (which is specified as part of select()'s parameters) was set too high judging from the overall content; Web servers and clients alike would suffer considerable latency as a result of waiting too long for I/O ports to activate. Thus it's likely the Apache install was misconfigured somehow, since the default settings should be sufficient for most purposes (in my limited experience since I work solely with nginx these days).
I had this problem writing a server in PHP, and it took a while to get PHP (under Win32) to stop hogging my precious CPU cycles by successful application of nonblocking sockets and a short timeout parameter. Thokling (talk) 15:24, 20 September 2013 (UTC)
- You are correct and I have modified the explanation. It could also be due to a loop polling a socket that will never be freed(a deadlock), this was my interpretation. 108.162.246.117 07:05, 1 November 2013 (UTC)
The explanations above don't seem to match "the load climbing out of control". The load typically means the CPU load, not latency. If the server is stuck on reading from a socket, the latency will grow but the load will plunge, since it's _waiting_ and thus not consuming the CPU cycles. Two typical problems connected with select() are: (1) As the number of sockets polled grows, the overhead of select() grows, so it uses more and more CPU just to go through all the sockets and check them all for readiness. (2) If some socket reports readiness through select() and then the program does not handle that readiness but keeps including this socket into the following select() calls, it will be stuck in a tight loop retrying select() and using all the available CPU of one processor. A less extreme variety of this case is the program being notified of multiple sockets being ready but handling only one socket before repeating select(). In this case the program will continue making progress but with the increased overhead of the unnecessary select() calls. 108.162.246.5 21:07, 30 January 2014 (UTC)
