From: APseudoUtopia on
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
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
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
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
>>>> 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
 |  Next  |  Last
Pages: 1 2
Prev: Error message
Next: Does anyone here use TCPDF?