hi Nathan, any chance of a 'full blown' example for all the muppets who want to try and grok this stuff? (bork bork, say I :-)) Nathan Rixham wrote: > 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
