Today, the PHPStorm + xdebug debugging environment has been set up in the past few days, and various problems have been encountered: A. access to ultra-slow responses and B. access to ultra-fast responses is A blank page. Problem A has many solutions, but there are still Solutions. problem B is probably A thread problem, too... today, the PHPStorm + xdebug debugging environment has been set up in the past few days, and various problems have been encountered: A. access to ultra-slow responses and B. access to ultra-fast responses is A blank page.
Problem A has many solutions, but there are still Solutions. problem B is probably A thread problem. maybe you can Debug php. the ini configuration may not be completed. it is difficult to clarify that the thread issue may be related to the xdebug version.
Solution: PHP. ini finds the memory_limit parameter, increases it, and changes to a browser. I used to debug the program using Google Chrome, and then started to slow down until every page became loaded in 6 seconds. Firefox and IE do not have this problem (this method is very useful and can work immediately !) Use the xdebug. profiler_enable_trigger configuration to run the xdebug function probe program.
The value of xdebug. remote_host should be the same as the IP address of your server. for example, if you access it through localhost, write localhost here. if you access it through 127.0.0.1, write it to 127.0.0.1.
Check whether your xdebug. profiler_output_dir Directory has reached several GB? (After a set of e-commerce programs are continuously developed for more than 10 hours, the xdebug file in the xdebug. profiler_output_dir directory reaches several GB !)
Close xdebug when you do not need it!
Xdebug. remote_enable = 0 xdebug. profiler_enable = 0 xdebug. remote_autostart = false
Last sentence: DON't run xdebug on production.
Article address:
Reprint at will ^ please include the address of this article!