Bug #67884 [Com]: Doing a request to itself causes a lock

From: Date: Thu, 27 Jul 2017 12:18:18 +0000
Subject: Bug #67884 [Com]: Doing a request to itself causes a lock
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-210368@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=67884&edit=1 ID: 67884 Comment by: cohan at icnerd dot com Reported by: jgmdev@php.net Summary: Doing a request to itself causes a lock Status: Not a bug Type: Bug Package: Built-in web server Operating System: Linux (Archlinux) PHP Version: 5.5.15 Block user comment: N Private report: N New Comment: > The embedded web server is for testing purpose and not meant as a full web server [..] there > are multiple good web servers already which work nicely with PHP. Any chance of this one being re-looked at? There are multiple dev use cases for this. For example both Laravel and WP CLI use the PHP built in server to test development with a simple "serve" command. Unfortunately if you happen to make a request within a script (such as to an API, also being tested) everything locks up. At the very least some form of error message to stderr if we're attempting to make a request to ourselves. At the moment there's no indication as to where the error is actually occurring. Previous Comments: ------------------------------------------------------------------------ [2014-10-16 17:24:58] johannes@php.net The embedded web server is for testing purpose and not meant as a full web server. This limitation along with others (like missing vhost support etc.) is by design and we don't have any plans to change that as there are multiple good web servers already which work nicely with PHP. ------------------------------------------------------------------------ [2014-08-22 18:59:14] jgmdev@php.net I see :(, looking at the code polling was used, well I'm not going to be able to test my system using the built-in server. Something like http://en.wikipedia.org/wiki/Multiple_asynchronous_periodic_polling would solve the issue, wonder how much work it would be to implement that. ------------------------------------------------------------------------ [2014-08-22 18:45:12] requinix@php.net With a sleep(1) in the router script I get Concurrency Level: 100 Time taken for tests: 1000.604 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 121000 bytes HTML transferred: 0 bytes Requests per second: 1.00 [#/sec] (mean) Time per request: 100060.414 [ms] (mean) Time per request: 1000.604 [ms] (mean, across all concurrent requests) Transfer rate: 0.12 [Kbytes/sec] received Given X=number of concurrent requests served by PHP, and a sleep(1) to account for the various "per second"-s, the report will say: - Time taken: 1000 [total time] / X - Requests per second: X - Mean time per request: 100 [concurrent requests by AB] * 1000 [msec. each] / X So it's not concurrent. Besides, I don't see any threading or forking going on in the source code. ------------------------------------------------------------------------ [2014-08-22 13:10:34] jgmdev@php.net I tested with ab -c 100 -n 1000 http://localhost:8001/ and a router file that doesn't request it self: <?php print "something"; And here are the results, which shows that the built-in server does supports concurrency/threading (unless it is happening so fast that feels like threading): Concurrency Level: 100 Time taken for tests: 0.075 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 118000 bytes HTML transferred: 7000 bytes Requests per second: 13335.82 [#/sec] (mean) Time per request: 7.499 [ms] (mean) Time per request: 0.075 [ms] (mean, across all concurrent requests) Transfer rate: 1536.75 [Kbytes/sec] received Also the meaning of "PHP applications will stall if a request is blocked" isn't clear. ------------------------------------------------------------------------ [2014-08-22 04:17:37] requinix@php.net Isn't the server single-threaded? The docs say right there at the top "PHP applications will stall if a request is blocked". ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=67884 -- Edit this bug report at https://bugs.php.net/bug.php?id=67884&edit=1

« previous php.bugs (#210368) next »