stream_socket_server simply listens, stream_socket_accept handles the
connection, stream_set_write_buffer and stream_set_blocking help you
keep up, especially when combined with stream_get_line, no need to shile
forever when you can just:
while (is_resource($conn = stream_socket_accept($socket, -1)))
while (is_resource($conn) && $pkt = stream_get_line($conn, 1000000, "\n"))
Key I find though is multithreading, listener thread with
stream_socket_server, 2 or 3 stream_socket_accept threads and a pair of
new thread spawned to handle each connection (one to read, one to write)
(not needed for stateless http style request processing).
Nathan
M5 wrote:
Curiously, would you agree with this guy's comments concerning low-level
PHP socket functions vs stream_socket_server() ?
"If you want a high speed socket server, use the low-level sockets
instead (socket_create/bind/listen). The stream_socket_server version
appears to have internal fixed 8k buffers that will overflow if you
don't keep up by reading.
This is a serious problem if you an application that reads the socket
for messages and then, say, saves the result in a database. The delay
while it is busy processing means you can't read the data in time unless
you get involved in muti-threading.
With the the low-level functions, the OS quietly buffers TCP/IP packets
so there is no problem (tested on Windows XP Professional)."
(http://www.php.net/manual/en/function.stream-socket-server.php#67837)
On 10-Dec-07, at 9:46 PM, Tom Rogers wrote:
Hi,
Tuesday, December 11, 2007, 10:01:38 AM, you wrote:
RF> On 10-Dec-07, at 4:42 PM, Tom Rogers wrote:
Put a usleep(1000) in the listen while() loop and give the cpu a
break.
RF> Good advice, but I've already been doing that. The thing is, when the
RF> script first starts up, the CPU rarely exceeds 30%, even when many
RF> clients (200+) are simultaneously connected and sending data. When a
RF> few clients are connected, CPU is typically below 10%. Again, it's
RF> only after 24-48 hours that, all of a sudden, CPU usage increases by
RF> 40-50%. And it stays high until I stop the script and restart it.
RF> One question I have though is, is there actually any benefit to using
RF> mysql_pconnect(), since the script simply loops? My understanding is
RF> that pconnect only benefits if a script would otherwise be using
RF> mysql_connect repeatedly--and this script doesn't, since it calls
RF> mysql_[p]connect() just once, in the start tof execution.
RF> ...Rene
I have found pconnect to be a problem (several years ago) and have
never tried it since, it may well be ok now. The most likely cause is
memory consumption on long running php scripts, what does top say?
I have a script which runs from cron and was hammering the system when
it ran and i have had to put the usleep() in the while($result = ..)
loop as there are a few thousand rows. Probably bad design but it
works and I'm loath to touch it :)
One way to solve the memory issue is to have the script started by
inetd, slower but more memory friendly.
Also have a look at memcached to reduce the load a bit.
--
regards,
Tom
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
