首頁 web前端 js教程 深入剖析浏览器退出之后php还会继续执行么_php实例

深入剖析浏览器退出之后php还会继续执行么_php实例

Jun 07, 2016 pm 05:07 PM
php執行 瀏覽器

前提:这里说的是典型的lnmp结构,nginx+php-fpm的模式

如果我有个php程序执行地非常慢,甚至于在代码中sleep(),然后浏览器连接上服务的时候,会启动一个php-fpm进程,但是这个时候,如果浏览器关闭了,那么请问,这个时候服务端的这个php-fpm进程是否还会继续运行呢?

今天就是要解决这个问题。

最简单的实验

最简单的方法就是做实验,我们写一个程序:在sleep之前和之后都用file_put_contents来写入日志:

<&#63;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函数相关。

于是我就把代码稍微改成这样的:

<&#63;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
}
登入後複製

服务端程序:

<&#63;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的影响。

程序就改成

<&#63;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还会继续执行么就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持脚本之家。

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

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

AI Clothes Remover

AI Clothes Remover

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

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

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

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

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

解決 Craft CMS 中的緩存問題:使用 wiejeben/craft-laravel-mix 插件 解決 Craft CMS 中的緩存問題:使用 wiejeben/craft-laravel-mix 插件 Apr 18, 2025 am 09:24 AM

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

apache服務器是什麼 apache服務器是乾嘛的 apache服務器是什麼 apache服務器是乾嘛的 Apr 13, 2025 am 11:57 AM

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

Nginx性能監控與故障排查工具使用 Nginx性能監控與故障排查工具使用 Apr 13, 2025 pm 10:00 PM

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

Tomcat日誌中如何查看線程狀態 Tomcat日誌中如何查看線程狀態 Apr 13, 2025 am 08:36 AM

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

HDFS文件系統在CentOS上的使用技巧 HDFS文件系統在CentOS上的使用技巧 Apr 14, 2025 pm 07:30 PM

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日誌分析與統計,了解網站訪問情況 Nginx日誌分析與統計,了解網站訪問情況 Apr 13, 2025 pm 10:06 PM

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

如何優化網站性能:使用Minify庫的經驗與教訓 如何優化網站性能:使用Minify庫的經驗與教訓 Apr 17, 2025 pm 11:18 PM

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

如何在CentOS上監控HDFS狀態 如何在CentOS上監控HDFS狀態 Apr 14, 2025 pm 07:33 PM

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

See all articles