Performance of while(true) loop
in [General]
|
Prev: Error message
Next: Does anyone here use TCPDF?
From: APseudoUtopia on 9 Sep 2009 22:32 Hey list, I have a php cli script that listens on a UDP socket and, when data is sent to the socket, the script inserts it into a database. I'm using the real BSD socket functions, not fsock. The script runs socket_create(), then socket_bind(). Then it starts a while(TRUE) loop. Within the loop, it runs socket_recvfrom(). I have it running 24/7 inside a screen window. I'm curious as to the cpu/memory/etc usage of a while(true) loop. The `top` command shows that the process is in the sbwait state (the OS is FreeBSD). I'm contemplating adding a usleep or even a sleep inside to loop. Would this be beneficial? I'm not too sure of how the internals of PHP work in terms of loops and such. Thanks.
From: Eddie Drapkin on 9 Sep 2009 22:39 On Wed, Sep 9, 2009 at 10:32 PM, APseudoUtopia <apseudoutopia(a)gmail.com> wrote: > Hey list, > > I have a php cli script that listens on a UDP socket and, when data is > sent to the socket, the script inserts it into a database. I'm using > the real BSD socket functions, not fsock. > > The script runs socket_create(), then socket_bind(). Then it starts a > while(TRUE) loop. Within the loop, it runs socket_recvfrom(). I have > it running 24/7 inside a screen window. > > I'm curious as to the cpu/memory/etc usage of a while(true) loop. The > `top` command shows that the process is in the sbwait state (the OS is > FreeBSD). I'm contemplating adding a usleep or even a sleep inside to > loop. Would this be beneficial? I'm not too sure of how the internals > of PHP work in terms of loops and such. > > Thanks. > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Is your socket blocking? If so, what's the timeout? while(true) { //wait for socket timeout } is the same as: while(true) { //read nothing from socket and sleep } Without the usleep(), the loop is going to loop as fast as your CPU will let it - meaning 100% CPU usage, all the time, at least in linux, although I'm pretty sure BSD would behave the same. As far as I'm aware, sockets in PHP behave almost identically to the way that they behave in C. I had an asynchronous TCP server written with the socket_* functions and noticed that the while(true) loop used 100% of the CPU because of the nonblocking sockets in use, but a usleep() solved that quite easily. Using blocking sockets with socket_select and a sane timeout relieved the high CPU usage as well.
From: APseudoUtopia on 9 Sep 2009 22:53 On Wed, Sep 9, 2009 at 10:39 PM, Eddie Drapkin<oorza2k5(a)gmail.com> wrote: > On Wed, Sep 9, 2009 at 10:32 PM, APseudoUtopia <apseudoutopia(a)gmail.com> wrote: >> Hey list, >> >> I have a php cli script that listens on a UDP socket and, when data is >> sent to the socket, the script inserts it into a database. I'm using >> the real BSD socket functions, not fsock. >> >> The script runs socket_create(), then socket_bind(). Then it starts a >> while(TRUE) loop. Within the loop, it runs socket_recvfrom(). I have >> it running 24/7 inside a screen window. >> >> I'm curious as to the cpu/memory/etc usage of a while(true) loop. The >> `top` command shows that the process is in the sbwait state (the OS is >> FreeBSD). I'm contemplating adding a usleep or even a sleep inside to >> loop. Would this be beneficial? I'm not too sure of how the internals >> of PHP work in terms of loops and such. >> >> Thanks. >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > Is your socket blocking? Â If so, what's the timeout? > > while(true) { > > //wait for socket timeout > > } > > is the same as: > > while(true) { > > //read nothing from socket and sleep > > } > > Without the usleep(), the loop is going to loop as fast as your CPU > will let it - meaning 100% CPU usage, all the time, at least in linux, > although I'm pretty sure BSD would behave the same. > > As far as I'm aware, sockets in PHP behave almost identically to the > way that they behave in C. Â I had an asynchronous TCP server written > with the socket_* functions and noticed that the while(true) loop used > 100% of the CPU because of the nonblocking sockets in use, but a > usleep() solved that quite easily. Â Using blocking sockets with > socket_select and a sane timeout relieved the high CPU usage as well. > I believe it is blocking. Here's my socket_recvfrom: $Recv = socket_recvfrom($Socket, $Data, 512, MSG_WAITALL, $Name, $Port); So I think the the MSG_WAITALL is causing it to block until incoming data connection is closed (it never reaches the 512 byte mark before it echos the data). Here's the full script, minus the debugging/error catching stuff: $Socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP); $Bind = socket_bind($Socket, '127.0.0.1', 1223); while(TRUE){ $Recv = socket_recvfrom($Socket, $Data, 512, MSG_WAITALL, $Name, $Port); print_r($Data); } As soon as the message is sent on the socket, it displays it. There's no delay until it builds up 512 bytes or anything. Also, I was playing around with ps and it looks like it's using 0% CPU, so I suppose it must be blocking. In the case that it is blocking, would it still be wise to throw a usleep in there just to be sure? Thanks.
From: Eddie Drapkin on 9 Sep 2009 23:25 On Wed, Sep 9, 2009 at 10:53 PM, APseudoUtopia <apseudoutopia(a)gmail.com> wrote: > On Wed, Sep 9, 2009 at 10:39 PM, Eddie Drapkin<oorza2k5(a)gmail.com> wrote: >> On Wed, Sep 9, 2009 at 10:32 PM, APseudoUtopia <apseudoutopia(a)gmail.com> wrote: >>> Hey list, >>> >>> I have a php cli script that listens on a UDP socket and, when data is >>> sent to the socket, the script inserts it into a database. I'm using >>> the real BSD socket functions, not fsock. >>> >>> The script runs socket_create(), then socket_bind(). Then it starts a >>> while(TRUE) loop. Within the loop, it runs socket_recvfrom(). I have >>> it running 24/7 inside a screen window. >>> >>> I'm curious as to the cpu/memory/etc usage of a while(true) loop. The >>> `top` command shows that the process is in the sbwait state (the OS is >>> FreeBSD). I'm contemplating adding a usleep or even a sleep inside to >>> loop. Would this be beneficial? I'm not too sure of how the internals >>> of PHP work in terms of loops and such. >>> >>> Thanks. >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> Is your socket blocking? Â If so, what's the timeout? >> >> while(true) { >> >> //wait for socket timeout >> >> } >> >> is the same as: >> >> while(true) { >> >> //read nothing from socket and sleep >> >> } >> >> Without the usleep(), the loop is going to loop as fast as your CPU >> will let it - meaning 100% CPU usage, all the time, at least in linux, >> although I'm pretty sure BSD would behave the same. >> >> As far as I'm aware, sockets in PHP behave almost identically to the >> way that they behave in C. Â I had an asynchronous TCP server written >> with the socket_* functions and noticed that the while(true) loop used >> 100% of the CPU because of the nonblocking sockets in use, but a >> usleep() solved that quite easily. Â Using blocking sockets with >> socket_select and a sane timeout relieved the high CPU usage as well. >> > > I believe it is blocking. Here's my socket_recvfrom: > $Recv = socket_recvfrom($Socket, $Data, 512, MSG_WAITALL, $Name, $Port); > > So I think the the MSG_WAITALL is causing it to block until incoming > data connection is closed (it never reaches the 512 byte mark before > it echos the data). Here's the full script, minus the debugging/error > catching stuff: > > $Socket = socket_create(AF_INET, SOCK_DGRAM, SOL_UDP); > $Bind = socket_bind($Socket, '127.0.0.1', 1223); > while(TRUE){ > $Recv = socket_recvfrom($Socket, $Data, 512, MSG_WAITALL, $Name, $Port); > print_r($Data); > } > > As soon as the message is sent on the socket, it displays it. There's > no delay until it builds up 512 bytes or anything. Also, I was playing > around with ps and it looks like it's using 0% CPU, so I suppose it > must be blocking. > > In the case that it is blocking, would it still be wise to throw a > usleep in there just to be sure? > > Thanks. > MSG_WAITALL will block until 512 bytes of $Data has been received (or a disconnect), so unless you're receiving a ridiculous amount of data every iteration, forcing your CPU usage to be very high (which you've said isn't the case :P) then there's no real reason to sleep every while iteration. The reason why you're not getting a delay is because your "clients" are not maintaining an open connection to the socket, so it'll output as soon as the remote client disconnects from your "server". I wouldn't necessarily say it's unwise or wise to sleep after every iteration, but it would depend on what kind of latency you need from your application, how much data it's receiving, etc. etc. Another thing you might want to consider about your design is that function, as you're using it, blocks until those 512 bytes have been read, so if a normal "request" (assuming a persistent connection) to your socket is <512 bytes, it could potentially sit there and wait indefinitely (not very likely). As it is, though, your server blocks (or sleeps, if you will) on the socket until a connection is made and it reads 512 bytes / the client disconnects, which seems to be doing well for your usage. The old adage "if it ain't broke, don't fix it" sort of applies here. Your program idles about at 0% CPU usage most of the time, for now. Until something changes, I'd leave it alone :)
From: Ben Dunlap on 10 Sep 2009 00:58
>>>> I have a php cli script that listens on a UDP socket and, when data is [8<] >> So I think the the MSG_WAITALL is causing it to block until incoming >> data connection is closed (it never reaches the 512 byte mark before [8<] > your "clients" are not maintaining an open connection to the socket, > so it'll output as soon as the remote client disconnects from your > "server". [8<] > if you will) on the socket until a connection is made and it reads 512 > bytes / the client disconnects, which seems to be doing well for your > usage. Sorry if I'm missing something obvious, but do the concepts of "connection", "close", and "disconnect" even apply in this case, since it's a UDP socket? Ben |