php 为什么本地开发时使用CURL请求本地URL会卡死【转】

_是在WIN下开发。配置是nignxphp mysql

默认时启动phpcgi是

D:php php-cgi.exe-b 127.0.0.1:9000 -c D:phpfindphpaphp.ini

先看NGINX配置

       location ~ .php(.*)$  {
           fastcgi_pass   127.0.0.1:9000;
           fastcgi_index  index.php;
           fastcgi_split_path_info ^((?U).+.php)(/?.+)$;
           fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
           fastcgi_param  PATH_INFO  $fastcgi_path_info;
           fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
           include        fastcgi_params;
       }

NGINX中,看PHP文件块fastcig-pass的设置值(127.0.0.1:9000)。设置都是以keepalive方式请求,接收到PHP文件时,交于后端过程PHPCGI解析处理(127.0.0.1:9000),等待响应。而在本地文件以CURL请求本地环境中PHP文件时,之前的PHP还在等待CURL后的结果,这时9000端口已经被占用。导致CURL一直在处于等待状态。不设置timeout超时,程序就会卡死。结果都是false

解决方案:

新开启一个phpcgi进程设置不同端口:

例D:phpphp-cgi.exe -b 127.0.0.1:9001 -c D:phpfindphpaphp.ini

在需要被CURL的端口或域名设置中设置。

       location ~ .php(.*)$  {
           fastcgi_pass   127.0.0.1:9001;
           fastcgi_index  index.php;
           fastcgi_split_path_info ^((?U).+.php)(/?.+)$;
           fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
           fastcgi_param  PATH_INFO  $fastcgi_path_info;
           fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
           include        fastcgi_params;
       }

这样就可以请求了。但是不能请求同一个域下的文件。

这样可以在nginx中使用php-cgi负载均衡:

        upstream backend{
            server 127.0.0.1:9000;
            server 127.0.0.1:9001;
        }
        location ~ .php(.*)$  {
            fastcgi_pass   backend;
            fastcgi_index  index.php;
            fastcgi_split_path_info  ^((?U).+.php)(/?.+)$;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            fastcgi_param  PATH_INFO  $fastcgi_path_info;
            fastcgi_param  PATH_TRANSLATED  $document_root$fastcgi_path_info;
            include        fastcgi_params;
        }

见效果:

wKiom1R34OaQKrP9AAIa2TRYdYU845.gif
 
原文链接:https://blog.51cto.com/aarons/1583871

原文地址:https://www.cnblogs.com/KillBugMe/p/13220668.html