该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-02-03
diogin 回复得好专业,学习了。
PHP 的多线程模式连 php 官方也不推荐,因为许多扩展都不是线程安全的。 |
|
返回顶楼 | |
发表时间:2009-02-03
dualface 写道 第三个我可以回答:如果是虚拟主机,只能模仿 cron。如果是自己的服务器,写个 php 脚本从 cron 调用就行了。至于异步调用确实做不到,只能用 ajax 或者队列+cron脚本来模拟。 谢谢回答. "模仿 cron"是不是指用一个特殊请求, 循环执行来模拟任务调度? 这样可能资源释放不干净, 除非另创建一个进程. 而如果"做不到异步调用", 是不是意味着PHP里不能创建新进程? |
|
返回顶楼 | |
发表时间:2009-02-03
至于性能,我打算做个测试,不过对 Ruby 不熟,所以只能测测 PHP 和 Python。测试环境和基准到时一并列出:
0. 静态文件,一个 7K 的 jpg; 1. PHP,单脚本文件,未加 APC,输出“hello, world”; 2. PHP,单脚本文件,加 APC(apc.stat=On),输出“hello, world”; 3. PHP,单脚本文件,加 APC(apc.stat=Off),输出“hello, world”; 4. PHP,跑我自己写的简陋框架,未加 APC,输出“hello, world”; 5. PHP,跑我自己写的简陋框架,加 APC(apc.stat=On),输出“hello, world”; 6. PHP,跑我自己写的简陋框架,加 APC(apc.stat=Off),输出“hello, world”; 7. Python,单 WSGI 脚本文件,输出“hello, world”; 8. Python,跑 Django,输出“hello, world”。 |
|
返回顶楼 | |
发表时间:2009-02-03
diogin 写道 PHP 脚本里没有线程的概念,只有 PHP 解释器的实现有线程与否的概念。PHP 解释器通过 TSRM 层来实现对 PHP 脚本屏蔽线程。 另外,PHP 解释器未必使用多进程的运行方式。在 Apache 下,它还可以嵌入多线程方式的 httpd 子进程,以多线程的方式来运行,一个线程对应一个 HTTP 请求的处理。当然此时如果 PHP 解释器的部分代码没有做到线程安全,那可能就会出问题(据称 PHP 解释器的核心部分都是线程安全的,不过可能有些扩展代码的质量不高,存在线程不安全的问题)。 关于 PHP 部分,robbin的说法基本是错误的。PHP 解释器进程持有它需要的所有资源,它也带 GC。 PHP 解释器进程有两层面的 GC,一层是在请求结束时必须释放所有该次请求内申请的资源,并清扫该次环境;另一层是在请求执行内,它也存在 GC,这就是通常所说的 GC,比如变量的引用计数实现。 谢谢. 这里的"PHP 解释器进程"是不是指解释器本身的进程?而它持有需要的所有资源. 而"PHP request模型 多进程运行"是不是指解释器进程创建的进程, 这种进程是否持有资源和GC? |
|
返回顶楼 | |
发表时间:2009-02-03
这个帖子看了好几天了,心里一直在想,会不会创造Ruby版最长跟贴记录..
|
|
返回顶楼 | |
发表时间:2009-02-04
icewubin 写道 koalant 写道 zope2/plone 还是一个产品化的东西,还是比较易用的,通过 product 也可以扩展,但是后来发展起来的 Zope3 就是相当复杂了,其复杂性可以和整个 J2ee 相比较,跟 zope2 根本就是两回事,真是“没有接口创造接口也要上”,简直就是 java 程序员的作品,最终闹的 java 这边没人喜欢, python 那边也没人喜欢,pyhton 程序员还是比较喜欢简单的东西的。
简单的来说: PHP 就是: Quick and Dirty Java 就是: Beauty and Slowly Ruby 就是: Quick and Beauty python 就是: Quick and Simple 是不是可以理解为java做的网站速度最慢? 不知道PHP dirty是不是说PHP写成框架,其实我认为框架的定义在于规范代码。 JAVA做WEB不慢吧。 |
|
返回顶楼 | |
发表时间:2009-02-04
硬件:
机器: ThinkPad T61p CPU : Core2 Duo T9300 2.5G 6M L2 RAM : 2G 软件: WindowsXP SP3 x86 Apache 2.2.11(KeepAlive=Off,ThreadsPerChild=150,MaxRequestsPerChild=0) PHP 5.2.6(mod_php + mod_rewrite,APC 为 3.1.0-dev) Python 2.5.4(mod_wsgi 2.3) Django 1.0.2 测试方法: ab -n 5000 -c 50 [url] 为使结果精确些,测试静态时把 PHP 和 Python 都去掉,测试 PHP 时把 Python 去掉,反之亦然。 测试结果: 0. 静态文件,一个 7K 的 jpg; 结果:[4050.63 reqs/sec] 1. PHP,单脚本文件,未加 APC,输出“hello, world”; 结果:[2782.61 reqs/sec] 2. PHP,单脚本文件,加 APC(apc.stat=On),输出“hello, world”; 结果:[2962.96 reqs/sec] 3. PHP,单脚本文件,加 APC(apc.stat=Off),输出“hello, world”; 结果:[2962.96 reqs/sec] 4. PHP,跑我自己写的简陋框架,未加 APC,输出“hello, world”; 结果:[ 307.99 reqs/sec] 5. PHP,跑我自己写的简陋框架,加 APC(apc.stat=On),输出“hello, world”; 结果:[1003.13 reqs/sec] 6. PHP,跑我自己写的简陋框架,加 APC(apc.stat=Off),输出“hello, world”; 结果:[1280.00 reqs/sec] 7. Python,单 WSGI 脚本文件,输出“hello, world”; 结果:[2560.00 reqs/sec] 8. Python,跑 Django,输出“hello, world”。 结果:[1939.39 reqs/sec] 结论: Django 的性能相当高,我自己写的简陋框架还得在性能方面多做努力。 有时间再测测其它框架。 |
|
返回顶楼 | |
发表时间:2009-02-04
最后修改:2009-02-04
diogin 写道 PHP 框架不是问题。关键是要找到一条“建设有 PHP 特色的框架开发之路”,而不是“照搬资本主义”。社会体质的不同造成了中国与大部分欧美国家发展之路的差异,中国经历了几代领导人才找到真正的出路,这点跟 PHP 目前的情况类似:PHP 的实现本质上就跟 Python/Ruby 的实现不同。 运行机制上的例子,随便举几个吧:你可以用 Python 脚本操纵线程,可以实现跨请求存在的变量,实现真正的对象(进程内对象,而非请求内对象,PHP 的类实际上只是一个跟请求有着相同生命期的瞬态对象,PHP 的对象就更不用说了),实现真正的工作单元模式(严肃的 ORM 都需要这个),实现真正的对象池、连接池、线程池,实现真正的异步I/O、非阻塞I/O,等等等等,你可以想象一下你用 C 写 HTTP Server 时需要考虑哪些,你就可以用 Python 去实现。 写PHP好多年了,到底什么算是“有 PHP 特色的框架开发之路”,一直雾里看花: 在特殊的PHP运行机制背景下,采用传统的OOP思想创建框架,不时的被质疑。这是完美主义者的洁癖?还是滑向深渊的开始? 如果彻底的按照PHP特性去设计框架,基本会是一个“字符串+数组”的框架,不会是什么“对象”框架。 PHP框架开发一方面要经受传统OOP思想的诱惑,一方面又要顾及PHP本身的特性。 这样看来,或许PHP里引入OOP模型本质上就是错误的。 越考虑越像哲学问题了。 |
|
返回顶楼 | |
发表时间:2009-02-04
robbin 写道 这本来是一个探讨PHP框架和Rails的话题,怎么又跑题到Java vs Ruby上去了? 跑题的家伙自己出来自首吧。
如果说语言的比较和借鉴是一个挺有意思的话题的话,那么搞xx PK xx就很无聊了。我们JavaEye网站实际上同时用到了Ruby,Java和PHP三种编程语言:Ruby用来做Web层,Java用来实现后台的全文检索服务器,而PHP用来实现邮件列表和邮件群发功能。所以我爱ruby,但是我也爱Java和PHP,如果将来JavaEye又用上了Python,你也不要吃惊,编程语言就是工具,工具是被你使用和玩的,而不是控制和玩你的。 |
|
返回顶楼 | |
发表时间:2009-02-04
最后修改:2009-02-04
dualface 写道 这和框架有什么关系?莫名其妙 奇了怪了,不是很多人在讨论,rails的框架是否在误导PHP框架(当然没有说一定在误导你)。不同的框架的实现方式当然各有不同,rails或者其他语言的框架采用OOP的思想,而PHP框架因为不借助其他技术无法简单基于这些理念来实现一些OOP中很容易实现的特点(不是说PHP弱,php有自己的特点优势),这怎么和框架没有关系? dualface 写道 b) 尽可能降低 bootstrap 成本:bootstrap 通常完成运行环境初始化、载入配置、连接数据库等。在 PHP 中,初始化运行环境并不存在什么问题,因为 PHP 本就是为 Web 应用设计的,启动 .php 程序时,运行环境就已经准备好了。而载入配置可以通过把配置文件解析为 php 数组后写入缓存文件,载入时直接 include 就可以获得设置,连序列化和反序列化都省了。最后的数据库连接,通过持久连接就能很好解决。而且访问量大了,再增加个第三方的连接池也不是难事。 其实你这段写得不错啊,你没有明白我的意思就认为我抬杠。 我之前提到配置文件,本来想说配置文件的作用不仅仅是载入配置信息,配置信息在不同的框架中会有进一步的作用,比如有人用xml配置信息来定义页面布局(假设有这个需求A),那你说的PHP数组优化手段就不能解决这类框架需求,不是说你的这种优化手段不好,而是反过来说PHP在做框架的时候有各种限制,不能乱用传统的OOP的思想,之前假设的需求A在PHP中可能就是不合理的设计。 所以没有抬杠的意思,可能我没说清楚我的意思,是我的不对。 dualface 写道 我认为 PHP 使用框架是一种必然趋势。因为 PHP 也在逐步进入更大规模的应用。比如淘宝,前端就开始逐步改为 PHP 了。虽然这种大型应用中,PHP 只是充当表现层和胶水的作用,但框架仍然能够带来很大的价值。框架可以让 PHP 应用开发更有规范性,从企业角度来说可以获得更高的可维护性。
这个你从哪里知道的?好像只是淘宝在新开功能的部分为了尽快的上应用,部分模块的使用PHP。他们的最主要的部分不可能替换成PHP的吧? |
|
返回顶楼 | |