What steps will reproduce the problem? 1. Enable xdebug profiling. 2. Create an AMQPConnection object. 3. Check the number of times AMQPConnection::__construct calls php::fread

What is the expected output? What do you see instead?

A literal reading of the PHP manual's page on stream_set_timeout suggests that fread will wait up to the timeout before returning, and only return early if data becomes available. What actually happens is that fread($this->sock) in AMQPReader::rawread returns "" (empty string) immediately on the majority of calls, immediately and without waiting. This in turn causes an excessive number of fread syscalls, driving up system time and CPU load.

What version of the product are you using? On what operating system?

amqplib trunk r24, on PHP 5.2.6 (Linux 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 i686 i386 GNU/Linux)

Please provide any additional information below.

Calling fread to read single bytes is also pretty lame. :)

Turns out this is a plain old-fashioned thinko: AMPQConnection::__construct takes $read_write_timeout but passes $rw_timeout. See patch.

As for reading single bytes via fread, this patch adds a simple-minded buffering layer to AMQPReader.

I noticed the amqp_consumer.php takes 100% cpu while waiting for commands. The problem is in AMQPReader::rawread that loop like crazy to read 1 byte. In the while loop I added a usleep(100) and it drop the CPU usage to around 50% while maintaining good performance.

100% CPU is a side effect of the bug my first patch (issue-6.patch) above fixes. With that sorted out, the number of calls to fread drops dramatically, reducing CPU load even without sleeps or buffering.

Oh much better patch!

Thanks!

patches are applied