深入剖析浏览器退出之后php还会继续执行么_php实例
前提:这里说的是典型的lnmp结构,nginx+php-fpm的模式
如果我有个php程序执行地非常慢,甚至于在代码中sleep(),然后浏览器连接上服务的时候,会启动一个php-fpm进程,但是这个时候,如果浏览器关闭了,那么请问,这个时候服务端的这个php-fpm进程是否还会继续运行呢?
今天就是要解决这个问题。
最简单的实验
最简单的方法就是做实验,我们写一个程序:在sleep之前和之后都用file_put_contents来写入日志:
<?php file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);
实际操作的结果是,我们在服务器sleep的过程中,关闭客户端浏览器,2222是会被写入日志中。
那么就意味着浏览器关闭以后,服务端的php还是会继续运行的?
ignore_user_abort
老王和diogin提醒,这个可能是和php的ignore_user_abort函数相关。
于是我就把代码稍微改成这样的:
<?php ignore_user_abort(false); file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);
发现并没有任何软用,不管设置ignore_user_abort为何值,都是会继续执行的。
但是这里有一个疑问: user_abort是什么?
文档对cli模式的abort说的很清楚,当php脚本执行的时候,用户终止了这个脚本的时候,就会触发abort了。然后脚本根据ignore_user_abort来判断是否要继续执行。
但是官方文档对cgi模式的abort并没有描述清楚。感觉即使客户端断开连接了,在cgi模式的php是不会收到abort的。
难道ignore_user_abort在cgi模式下是没有任何作用的?
是不是心跳问题呢?
首先想到的是不是心跳问题呢?我们断开浏览器客户端,等于在客户端没有close而断开了连接,服务端是需要等待tcp的keepalive到达时长之后才会检测出来的。
好,需要先排除浏览器设置的keepalive问题。
抛弃浏览器,简单写一个client程序:程序连接上http服务之后,发送一个header头,sleep1秒就主动close连接,而这个程序并没有带http的keepalive头。
程序如下:
package main import "net" import "fmt" import "time" func main() { conn, _ := net.Dial("tcp", "192.168.33.10:10011") fmt.Fprintf(conn, "GET /index.php HTTP/1.0\r\n\r\n") time.Sleep(1 * time.Second) conn.Close() return }
服务端程序:
<?php ignore_user_abort(false); file_put_contents('/tmp/test.log', '11111' . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); file_put_contents('/tmp/test.log', '2222' . PHP_EOL, FILE_APPEND | LOCK_EX);
发现仍然还是一样,php还是不管是否设置ignore_user_abort,会继续执行完成整个脚本。看来ignore_user_abort还是没有生效。
如何触发ignore_user_abort
那该怎么触发ignore_user_abort呢?服务端这边怎么知晓这个socket不能使用了呢?老王和diogin说是不是需要服务端主动和socket进行交互,才会判断出这个socket是否可以使用?
另外,我们还发现,php提供了connection_status和connection_aborted两个方法,这两个方法都能检测出当前的连接状态。于是我们的打日志的那行代码就可以改成:
file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . "abort:" . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX);
根据手册连接处理显示我们可以打印出当前连接的状态了。
下面还缺少一个和socket交互的程序,我们使用echo,后面也顺带记得带上flush,排除了flush的影响。
程序就改成
<?php ignore_user_abort(true); file_put_contents('/tmp/test.log', '1 connection status: ' . connection_status() . "abort:" . connection_aborted() . PHP_EOL, FILE_APPEND | LOCK_EX); sleep(3); for($i = 0; $i < 10; $i++) { echo "22222"; flush(); sleep(1); file_put_contents('/tmp/test.log', '2 connection status: ' . connection_status() . "abort:" . connection_aborted(). PHP_EOL, FILE_APPEND | LOCK_EX); }
很好,执行我们前面写的client。观察日志:
1 connection status: 0abort:0 2 connection status: 0abort:0 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1 2 connection status: 1abort:1
终于制造出了abort。日志也显示后面几次的abort状态都是1。
但是这里有个奇怪的地方,为什么第一个2 connection status的状态还是0呢(NORMAL)。
RST
我们使用wireshark抓包看整个客户端和服务端交互的过程
这整个过程只有发送14个包,我们看下服务端第一次发送22222的时候,客户端返回的是RST。后面就没有进行后续的包请求了。
于是理解了,客户端和服务端大概的交互流程是:
当服务端在循环中第一次发送2222的时候,客户端由于已经断开连接了,返回的是一个RST,但是这个发送过程算是请求成功了。直到第二次服务端再 次想往这个socket中进行write操作的时候,这个socket就不进行网络传输了,直接返回说connection的状态已经为abort。所以 就出现了上面的情况,第一次222是status为0,第二次的时候才出现abort。
strace进行验证
我们也可以使用strace php -S XXX来进行验证
整个过程strace的日志如下:
close(5) = 0 lstat("/tmp/test.log", {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0 open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873651, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "1 connection status: 0abort:0\n", 30) = 30 close(5) = 0 sendto(4, "HTTP/1.0 200 OK\r\nConnection: clo"..., 89, 0, NULL, 0) = 89 sendto(4, "111111111", 9, 0, NULL, 0) = 9 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({3, 0}, 0x7fff60a40290) = 0 sendto(4, "22222", 5, 0, NULL, 0) = 5 open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873681, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 0abort:0\n", 30) = 30 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0x7fff60a40290) = 0 sendto(4, "22222", 5, 0, NULL, 0) = -1 EPIPE (Broken pipe) --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2819, si_uid=0} --- open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 1abort:1\n", 30) = 30 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0x7fff60a40290) = 0 open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873741, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 1abort:1\n", 30) = 30 close(5) 。。。我们照中看status从0到1转变的地方。 ... sendto(4, "22222", 5, 0, NULL, 0) = 5 ... write(5, "2 connection status: 0abort:0\n", 30) = 30 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({1, 0}, 0x7fff60a40290) = 0 sendto(4, "22222", 5, 0, NULL, 0) = -1 EPIPE (Broken pipe) --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=2819, si_uid=0} --- open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=49873711, ...}) = 0 lseek(5, 0, SEEK_CUR) = 0 lseek(5, 0, SEEK_CUR) = 0 flock(5, LOCK_EX) = 0 write(5, "2 connection status: 1abort:1\n", 30) = 30 close(5)
第二次往socket中发送2222的时候显示了Broken pipe。这就是程序告诉我们,这个socket已经不能使用了,顺便php中的connection_status就会被设置为1了。后续的写操作也都不会再执行了。
总结
正常情况下,如果客户端client异常推出了,服务端的程序还是会继续执行,直到与IO进行了两次交互操作。服务端发现客户端已经断开连接,这个 时候会触发一个user_abort,如果这个没有设置ignore_user_abort,那么这个php-fpm的程序才会被中断。
至此,问题结了。
以上这篇深入剖析浏览器退出之后php还会继续执行么就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持脚本之家。

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

在使用CraftCMS開發網站時,常常會遇到資源文件緩存的問題,特別是當你頻繁更新CSS和JavaScript文件時,舊版本的文件可能仍然被瀏覽器緩存,導致用戶無法及時看到最新的更改。這個問題不僅影響用戶體驗,還會增加開發和調試的難度。最近,我在項目中遇到了類似的困擾,經過一番探索,我找到了wiejeben/craft-laravel-mix這個插件,它完美地解決了我的緩存問題。

Apache服務器是強大的Web服務器軟件,充當瀏覽器與網站服務器間的橋樑。 1. 它處理HTTP請求,根據請求返回網頁內容;2. 模塊化設計允許擴展功能,例如支持SSL加密和動態網頁;3. 配置文件(如虛擬主機配置)需謹慎設置,避免安全漏洞,並需優化性能參數,例如線程數和超時時間,才能構建高性能、安全的Web應用。

Nginx性能監控與故障排查主要通過以下步驟進行:1.使用nginx-V查看版本信息,並啟用stub_status模塊監控活躍連接數、請求數和緩存命中率;2.利用top命令監控系統資源佔用,iostat和vmstat分別監控磁盤I/O和內存使用情況;3.使用tcpdump抓包分析網絡流量,排查網絡連接問題;4.合理配置worker進程數,避免並發處理能力不足或進程上下文切換開銷過大;5.正確配置Nginx緩存,避免緩存大小設置不當;6.通過分析Nginx日誌,例如使用awk和grep命令或ELK

要查看Tomcat日誌中的線程狀態,您可以採用以下幾種方法:TomcatManagerWeb界面:在瀏覽器中輸入Tomcat的管理地址(通常為http://localhost:8080/manager),登錄後即可查看線程池的狀態。 JMX監控:使用JMX監控工具(如JConsole)連接到Tomcat的MBean服務器,查看Tomcat線程池的狀態。在JConsole中選擇

CentOS系統下HDFS文件系統的安裝、配置及優化指南本文將指導您如何在CentOS系統上安裝、配置和優化Hadoop分佈式文件系統(HDFS)。 HDFS安裝與配置Java環境安裝:首先,確保已安裝合適的Java環境。編輯/etc/profile文件,添加以下內容,並將/usr/lib/java-1.8.0/jdk1.8.0_144替換為您的實際Java安裝路徑:exportJAVA_HOME=/usr/lib/java-1.8.0/jdk1.8.0_144exportPATH=$J

本文介紹瞭如何分析Nginx日誌以提升網站性能和用戶體驗。 1.理解Nginx日誌格式,例如時間戳、IP地址、狀態碼等;2.使用awk等工具解析日誌,統計訪問量、錯誤率等指標;3.根據需求編寫更複雜的腳本或使用更高級工具,例如goaccess,分析不同維度的數據;4.對於海量日誌,考慮使用Hadoop或Spark等分佈式框架。通過分析日誌,可以識別網站訪問模式、改進內容策略,並最終優化網站性能和用戶體驗。

在開發網站的過程中,提升頁面加載速度一直是我的首要任務之一。曾經,我嘗試使用Minify庫來壓縮和合併CSS及JavaScript文件,以期提升網站的性能。然而,使用過程中遇到了不少問題和挑戰,最終讓我意識到Minify可能不再是最佳選擇。下面我將分享我的使用經驗,以及如何通過Composer安裝和使用Minify的過程。

在CentOS系統上監控HDFS(Hadoop分佈式文件系統)狀態有多種途徑。本文將介紹幾種常用方法,助您選擇最合適的方案。 1.利用Hadoop自帶的WebUIHadoop自帶的Web界面提供集群狀態監控功能。步驟:確保Hadoop集群已啟動並運行。訪問WebUI:在瀏覽器中輸入http://:50070(Hadoop2.x)或http://:9870(Hadoop3.x)。默認用戶名和密碼通常為hdfs/hdfs。 2.命令行工具監控Hadoop提供一系列命令行工具,方便監
