PHP web server 随想
最近和朋友讨论个问题,是用PHP作为web server,初衷是为了要在原本的基础上提升系统的效率。
首先这样做的原因是由PHP的特性造成的,对于一个PHP应用的每次请求,都会初始化一系列的资源,请求结束的时候,释放这些资源。问题是显而易见的,必定会有一些资源是在重复初始化和释放,造成系统资源的浪费。
用PHP 作为server的做法是,将请求全部定位到PHP的一次请求处理中,做死循环,解析请求资源,路由到相应的function,可以理解为局部应用,这样 做是在一次请求中,zend引擎不会释放任何资源,这里我把资源分为两类,一是app 应用的框架的资源,二是每次请求独立的资源。PHP 的web server 资源管理完全在PHP 脚本实现,效率比较起正常的apache+mod_php5 高很多,弊端是极为容易造成内存泄露,为应用添加功能的时候,只能在局限在函数中(函数中是局部变量),并且对于变量的命名要很注意,同时对于PHP编码 要求比较高。
我认为这种做法应该站在几个方面来考虑。
首先从大得方面来讲,在PHP脚本层面做server 来说,对于PHP来说是"返璞归真"的一种表现。个人觉得有悖于软件发展的规律,zend为初始化以及释放每次资源做了大量的工作,为的就是代码编写的简 单,降低PHP的门槛,做应用的时候,加上熟悉开源的MySql,可以快速,高效的开发应用,风靡全球。但正是由于这种原因,程序员不在关心内存,不再关 心关心数据结构,因为数据的查找,排序会交给数据库来完成。一度时间,PHP被甚至被称为草根阶级,也不是没有道理,是值得我们深思的一个问题。
从小的方面来讲,这样带来的好处是在小范围内极大的提高系统的效率,节省大量资源,要是只是代码编写习惯上一些细微的改变,在公司内部部署还是一个很好的选择,而且增加新的高效的应用的起点也比较低。
假如是要正常的思维,是要开发一个框架的模块,将每次请求重复初始化框架的一些资源初始化在PHP的启动阶段,这样做的缺点有:首先用C语言开发一个框架作为扩展的成本比较高。然后每次请求的资源不能重用,对于这种弊病,实际上在很久之前本人就开始考虑开发一个扩展,能够将请求的资源注册到全局,来实现 资源的高效重用。想要对请求资源的重用几乎要对zend源码做改动,而不是仅仅做扩展,成本有会增加。
总得来讲,效率和成本是不可能同时存在的,正所谓鱼和熊掌不可兼得。考虑自身的情况来实现任意一种方案来实现高效都是合理的,因为:存在的,就是合理的。

热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

记事本++7.3.1
好用且免费的代码编辑器

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

禅工作室 13.0.1
功能强大的PHP集成开发环境

Dreamweaver CS6
视觉化网页开发工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

热门话题

Laravel使用其直观的闪存方法简化了处理临时会话数据。这非常适合在您的应用程序中显示简短的消息,警报或通知。 默认情况下,数据仅针对后续请求: $请求 -

PHP客户端URL(curl)扩展是开发人员的强大工具,可以与远程服务器和REST API无缝交互。通过利用Libcurl(备受尊敬的多协议文件传输库),PHP curl促进了有效的执行

Laravel 提供简洁的 HTTP 响应模拟语法,简化了 HTTP 交互测试。这种方法显着减少了代码冗余,同时使您的测试模拟更直观。 基本实现提供了多种响应类型快捷方式: use Illuminate\Support\Facades\Http; Http::fake([ 'google.com' => 'Hello World', 'github.com' => ['foo' => 'bar'], 'forge.laravel.com' =>

您是否想为客户最紧迫的问题提供实时的即时解决方案? 实时聊天使您可以与客户进行实时对话,并立即解决他们的问题。它允许您为您的自定义提供更快的服务

文章讨论了PHP 5.3中引入的PHP中的晚期静态结合(LSB),从而允许静态方法的运行时分辨率调用以获得更灵活的继承。 LSB的实用应用和潜在的触摸
