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
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 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
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
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 process id of php deamon
Yep, that's it. You'll probably want to record the output for analysis,
but sometimes it's very
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
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 =
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
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 request
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 for stateless
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 can't be
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
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 unsure
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 and/or
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
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
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.
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 incoming
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
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 setup your
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 may still
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
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 to clean them up.
René Fournier wrote:
FWIW, here's the stripped-down skeleton of the server:
As always, constructive criticism is very welcome.
?php
$socket = stream_socket_server(tcp://127.0.0.1:9876, $errno, $errstr);
if ($socket) {
$master[] = $socket;
$read = $master;
$write = $master;
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
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
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
27 matches
Mail list logo
