Rumah >pembangunan bahagian belakang >tutorial php >不是很理解PHP的运行机制,求解

不是很理解PHP的运行机制,求解

WBOY
WBOYasal
2016-08-04 09:20:121095semak imbas

像java、nodejs,应该都是在服务端持续运行的一个程序,这个程序会一直运行,会占用cpu,会占用内存,接到网络请求,就会处理。

而PHP似乎不是一个程序,更类似于html,只有打开的时候才会执行,当没有人访问php的服务时,php甚至一点点内存都不占,一点点cpu都不占,是这样吗?


如果是这样,那php不是很难封装数据库class?因为每个用户进来都要给他开一个进程,进程之间互不相通,A用户进来给他开一个数据库连接,B用户进来又要给他单独开数据库连接。那php不是在不断连接和断开数据库?用户多了之后,开销应该很大吧?


这也是导致php没有类似js的 setInterval 或者 setTimeout 函数的原因吗?

回复内容:

像java、nodejs,应该都是在服务端持续运行的一个程序,这个程序会一直运行,会占用cpu,会占用内存,接到网络请求,就会处理。

而PHP似乎不是一个程序,更类似于html,只有打开的时候才会执行,当没有人访问php的服务时,php甚至一点点内存都不占,一点点cpu都不占,是这样吗?


如果是这样,那php不是很难封装数据库class?因为每个用户进来都要给他开一个进程,进程之间互不相通,A用户进来给他开一个数据库连接,B用户进来又要给他单独开数据库连接。那php不是在不断连接和断开数据库?用户多了之后,开销应该很大吧?


这也是导致php没有类似js的 setInterval 或者 setTimeout 函数的原因吗?

以PHP-FPM为例(类似Apache MOD_PHP)说说PHP的运行机制.
首先,PHP-FPM是一个C实现的多进程FastCGI服务.
每个PHP-FPM工作进程都内置了PHP解释器,不依赖PHP-CGI,都支持后台常驻,比如配置:

<code>nginx.conf: 访问io.php的请求都交给监听9001的PHP-FPM进程池处理
location = /io.php {
    include fastcgi_params;
    fastcgi_pass 127.0.0.1:9001;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

php-fpm: 正常脚本由静态www池处理,阻塞脚本由动态io池处理
[www]
;名为www的进程池监听9000端口,常驻进程数量为固定4个
listen = 127.0.0.1:9000
pm = static
pm.max_children = 4
[io]
;名为io的进程池监听9001端口,进程数常驻4个,最大8个
listen = 127.0.0.1:9001
pm = dynamic
pm.max_children = 8
pm.start_servers = 4
pm.min_spare_servers = 4
pm.max_spare_servers = 4</code>

PHP-FPM主进程就是用来管理这些工作进程的,比如一个工作进程被杀死了,立马重建一个.
PHP-FPM提供给了pm.status_path来通过浏览器查看整套PHP-FPM服务的工作状态.
像执行超时放弃,处理指定请求数后自动重启工作进程,慢日志记录(找出耗时的文件和函数)都支持.

而且开启持久连接后,每个PHP-FPM工作进程都能保持一个到MySQL的长连接不释放,避免重复连接数据库.
比如下图展示的是2个PHP-FPM进程跟MySQL建立的2个长连接:
不是很理解PHP的运行机制,求解
另外,针对Memcached和Redis的PECL扩展也都实现了持久连接的功能.

上面说了PHP-FPM的体系,下面就该说说PHP脚本在PHP-FPM体系下的生命周期.
PHP脚本里的量(包括全局变量)的生命周期只存在于一次请求内,请求处理完成,PHP-FPM就自动释放资源.
一次请求释放一次资源,这种内存释放是非常彻底的,PHP基于引用计数的GC甚至都还没发挥作用程序就已经结束了.
这里的释放资源指的是脚本里控制的资源,而不会干预到PHP-FPM常驻进程,不会让PHP-FPM进程关闭,也不能让PHP-FPM关闭到MySQL的持久连接,PHP-FPM只负责输入PHP脚本,执行PHP操作,如果加入了ZendOpcache支持,还可以把解析PHP脚本生成的opcode全部缓存到内存里共下次直接解释执行.PHP7中还支持用opcache.file_cache导出脚本opcode实现源代码保护.

PHP的一些常识:
数据库连接池: PHP持久连接就是天然的透明的无需程序干预的连接池,支持MySQL/Memcached/Redis等.
内存常驻: PHP-FPM进程,ZendOpcache缓存的脚本的opcode,鸟哥开发的Yac都是内存常驻的.
垃圾回收: PHP-FPM一次请求释放一次资源的运行模式,削弱了基于引用计数的GC的作用.

最后,CLI下工作的PHP守护进程服务比如Swoole/WorkerMan才跟Java/Node之类相似.

虽然我已经下班了,看到你这个提说PHP是类似html我忍不了。PHP功能是html无法比拟的好不好,就拿你说的连接数据库的例子来说,html能连接数据吗?能读取数据库内容吗?不能吧!还有你说多个用户来访问每个用户都要开一个数据库连接,你这样太小看PHP了。封装一个数据库连接类很简单很简单,这些我就不贴code了。PHP手册每种数据库扩展都有介绍也有事例,你可以自己做参考。你既然提到java那肯定也知道单例模式吧!PHP封装好一个数据库连接类设置单例模式就可以实现数据连接静态化。不管多少用户来访问直接调用一下就可以不是你说的多个用户来访问就开多个进程。还有你提到的setIntervalsetTimeout不就是定时执行吗!PHP也可以的啊!首先定义好PHP要实现的功能,然后通过在服务器上设置crontab就可以了,参数自己设置就行,或者还有php-fpm。还有等等等的功能我就不罗列了,也没整理答案格式你先凑活着看。我得下班走人了,有问题咱明天继续讨论

总之,PHP是一门很好很好的语言,功能很强大……而且还在不断的发展壮大中……易学易懂啊!兄弟

PHP不能常驻内存,每一个HTTP请求开后,连接数据库,等请求结束了,数据库连接 和 各种变量都释放掉了。

你总体上的理解是对的,但的不是所有的语言都是java那种常驻内存的,python,go,c都不是。PHP也确实没有链接池的概念,进程执行完就好释放掉,不会留着给其他进程用

给你 《深入理解 PHP 内核》第二章第一节的内容链接:

http://www.php-internals.com/...

你的疑惑,只是因为你只看到了表面。

如果你用过 swoole,我想你肯定不会提出这种问题。

呃,你当php-fpm没到。。。

而PHP似乎不是一个程序,更类似于html

PHP只是可以嵌入到HTML中,但跟HTML是天壤之别,PHP有很多扩展可以做不同的事情,HTML能吗?

只有打开的时候才会执行,当没有人访问php的服务时,php甚至一点点内存都不占,一点点cpu都不占,是这样吗?

PHP主要有两种运行方式(除了CLI):
1.Apache为代表的mod_php,这时工作是交给Apache处理了。
2.Nginx/Lighttpd用的php-fpm(fastcgi进程管理器),这个是常驻的守护进程。
所以说,怎么可能不占CPU和内存?

如果是这样,那php不是很难封装数据库class?因为每个用户进来都要给他开一个进程,进程之间互不相通,A用户进来给他开一个数据库连接,B用户进来又要给他单独开数据库连接。那php不是在不断连接和断开数据库?用户多了之后,开销应该很大吧?

以MySQL为例,如果连接时选择pconnect(持久连接)的话,下次就会直接使用已存在的连接,不会关闭连接。
PDO也有长连接选项。

这也是导致php没有类似js的setInterval或者setTimeout函数的原因吗?

PHP是有延时函数(如sleep())的哦,而且精度比JS的高太多太多了(微秒级别)。

好热闹啊。 @ivanilla 的回答与评论包含好多信息,感谢。

其实我认为针对楼主的问题,PHP的运行机制就是解释执行脚本。PHP是为中小型网站提供服务端支持的脚本语言,在开发速度与运行效率上具有良好的平衡,这是它成功的原因。

所以楼主的其它观点就没啥看头了,连争论都无意义,如果PHP拥有了你想像的那些东西,这个语言也就没人用了,大家干脆还是用java好了。

楼主对PHP的一些基础知识不了解,应该是刚开始接触PHP。简单来说PHP可以以两种模式运行,一种是脚本方式,如在 shell 里执行 php xxx.php;一种是楼主理解的有网络请求才启动运行(不是十分贴切),有编译成apache的扩展方式,也有fast-cgi方式。apache的mod_php方式就是来一个请求起一个进程执行,效率底下,相应的有各种参数优化等。而fast-cgi则要高效得多,具体的楼主可以翻看相应的手册并实际操作一下。

楼上几位真有耐心

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn