M5 wrote:
On 20-Dec-07, at 1:17 AM, Per Jessen wrote:
René Fournier wrote:
I'm really not sure what to try next. ps -aux shows MySQL as hogging
the CPU, not PHP or Terminal:
When this happens, do a 'SHOW PROCESSLIST' in mysql to see what it's
doing.
I have, and I can't see anything unusu
On 20-Dec-07, at 1:17 AM, Per Jessen wrote:
René Fournier wrote:
I'm really not sure what to try next. ps -aux shows MySQL as hogging
the CPU, not PHP or Terminal:
When this happens, do a 'SHOW PROCESSLIST' in mysql to see what it's
doing.
I have, and I can't see anything unusual. There a
René Fournier wrote:
> I'm really not sure what to try next. ps -aux shows MySQL as hogging
> the CPU, not PHP or Terminal:
When this happens, do a 'SHOW PROCESSLIST' in mysql to see what it's
doing.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit:
On 11-Dec-07, at 2:13 PM, Per Jessen wrote:
René Fournier wrote:
However, the number of socket clients connecting in the past 3-4
months has steadily increased, and this seems to have exposed (if not
created) a strange performance "issue" with PHP 5.2.4, MySQL 5.0.45
and/or Mac OS X Server 10
Jochem Maas wrote:
>> Have you tried stracing it to see what's really happening when the
>> load goes that high?
>
> am I correct that that would be done like so?:
>
> strace -p
Yep, that's it. You'll probably want to record the output for analysis,
but sometimes it's very obvious what's happ
Per Jessen wrote:
> René Fournier wrote:
>
>> However, the number of socket clients connecting in the past 3-4
>> months has steadily increased, and this seems to have exposed (if not
>> created) a strange performance "issue" with PHP 5.2.4, MySQL 5.0.45
>> and/or Mac OS X Server 10.4.11. (I say "
René Fournier wrote:
> However, the number of socket clients connecting in the past 3-4
> months has steadily increased, and this seems to have exposed (if not
> created) a strange performance "issue" with PHP 5.2.4, MySQL 5.0.45
> and/or Mac OS X Server 10.4.11. (I say "and/or" because I am unsur
That makes sense, but I'm not sure I really want to do this, since
it's fairly important that Listener continue listening without
interruption.
I also don't think it's probably necessary, since from what I read,
I'm not really pushing the envelope in terms of real load. Right now,
I might
Jochem Maas wrote:
>> I'd be interested to see how he does the multi-threading in php.
>> Personally I'd always opt for C to write this type of thing, except
>> for perhaps the most simple cases.
>>
>
> any chance of an example from you too?
Sure -
http://jessen.ch/files/distripg_main.c
It c
Per Jessen wrote:
> Jochem Maas wrote:
>
>> Nathan Rixham wrote:
>>> 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 fo
Jochem Maas wrote:
> Nathan Rixham wrote:
>>
>> 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 r
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
> kee
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
M5 wrote:
Thanks Jim.
No problem.
The processing is pretty quick. I don't think that's a bottleneck. It
basically just inserts the data into MySQL, not much processing actually.
What is the likely hood that two connections would come in at the same
time, or at least within close enough
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 8
Thanks Jim. Several good points here that I will look into. I've
already moved the include() bits into function calls. (That's simple
thing I should have corrected long ago.) The socket areas though I'm
less sure about how to adjust, since networking programming isn't
something I grok natur
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 r
René Fournier wrote:
FWIW, here's the stripped-down skeleton of the server:
As always, constructive criticism is very welcome.
$master[] = $socket;
$read = $master;
$write = $master;
while (1) {
$read = $master;
$write = $master;
Jochem Maas wrote:
> Jim Lucas wrote:
>> Tom Rogers wrote:
>>> Hi,
>
> ...
>
>> Also, make sure you are not using an array that you are not re-initializing
>> through each iteration
>> of the loop. If the array keeps getting bigger, PHP might $*%& on itself.
>> Always re-initialize
>> arrays
On 10-Dec-07, at 5:20 PM, Jim Lucas wrote:
Tom Rogers wrote:
Hi,
Tuesday, December 11, 2007, 6:42:18 AM, you wrote:
RF> Hello,
Put a usleep(1000) in the listen while() loop and give the cpu a
break.
This makes me think about asking if you have to short of a timeout
on your receiving conn
Jim Lucas wrote:
> Tom Rogers wrote:
>> Hi,
...
> Also, make sure you are not using an array that you are not re-initializing
> through each iteration
> of the loop. If the array keeps getting bigger, PHP might $*%& on itself.
> Always re-initialize
> arrays to clean them up.
even then he ma
Tom Rogers wrote:
> Hi,
>
> Tuesday, December 11, 2007, 6:42:18 AM, you wrote:
> RF> Hello,
>
> Put a usleep(1000) in the listen while() loop and give the cpu a
> break.
>
This makes me think about asking if you have to short of a timeout on your
receiving connection?
What are you using to se
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.
Good advice, but I've already been doing that. The thing is, when the
script first starts up, the CPU rarely exceeds 30%, even when many
clients (200+) are simultaneously c
Hi,
Tuesday, December 11, 2007, 6:42:18 AM, you wrote:
RF> Hello,
RF> I have a command-line PHP script--called Listener--that is designed
RF> to run indefinitely with a predictable CPU usage and memory
RF> footprint. In a nutshell, it's a multi-client socket server that
RF> waits for incomi
Hi Jim,
I have a server that "listens" like yours does. I get 80k - 85k
connections a day to it.
When I first started it, I was only getting about 3k of connections
aday. Then I upped the
listening pattern and it tanked. I noticed that all my mail/web/db
connections just sat there.
René Fournier wrote:
> Hello,
>
> I have a command-line PHP script--called Listener--that is designed to
> run indefinitely with a predictable CPU usage and memory footprint. In a
> nutshell, it's a multi-client socket server that waits for incoming
> connections, processes incoming data, stores r
Hello,
I have a command-line PHP script--called Listener--that is designed
to run indefinitely with a predictable CPU usage and memory
footprint. In a nutshell, it's a multi-client socket server that
waits for incoming connections, processes incoming data, stores
results in a MySQL databa
27 matches
Mail list logo