Tag Archives: PHP

关于 Discuz! 的二次开发

可能是因为 Discuz! 庞大的用户群的原因吧，发现有些中小网站也有在 Discuz! 基础上做二次开发的，巧的是，到了某个阶段，不约而同的遇到类似的问题：开发进度明显滞后。

个人觉得 Discuz! 设计的初衷是面向中小站长的，对于二次开发可能并不是很重视。去官方论坛看了半天，甚至都没有专门二次开发的板块。莫非大家的二次开发都是各自为政，摸着黑搞的么?(好像的确是这样，代码开源，对着修改就成) 一些简单的门户开发估计问题都不大的，如果业务复杂一些，并且流量相对较大，可能隐忧就会比较明显了。

有次因为要验证一点东西，看了一点 Discuz! 的代码，发现一些基本的模块性能上并非很好(我自己并不很懂 PHP，只是出于性能考虑罢了)，类似的页面在一定规模下并不会对性能有太大影响，可一旦突破某个量级，影响就非常明显了。有的网友可能会说，别装了，你不知道 Discuz! 功能有多强大吧? 问题可能恰恰就在于功能强大这儿了，一个软件如果自身已经在一些细节上考虑的足够细致，那么无疑也会给二次开发带来不必要的开销。就这一点上说，或许 Discuz! 有必要开发一个面向二次开发的版本，削减一些锦上添花的小功能。

另外，UCenter 这个 SNS 产品我觉得也不会有太大作为，千站一面的 SNS ，除了让大家消磨一些无谓的时间，会带来什么创新呢?

这只是我心血来潮，对产品设计的一点思考罢了，可别真的绕到 Discuz! 到底有哪些优点上去…

–EOF–
更新，有朋友和我说

Discuz! 代码里面本身包含监控隐私的东西，如果你的网站达到一定数量的用户，程序会触发通知 Discuz! 公司。

谁来证实一下?

附加阅读:

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

PHP FastCGI 进程管理器: PHP-FPM

最近 PHP-FPM (PHP FastCGI Process Manager) 这个话题在讨论组里很受关注。使用 PHP 的朋友对于 FastCGI 进程的管理估计都很头疼，比如 Nginx 下的 FastCGI 就有不少人用的 Lighttpd 的 spawn-fcgi 来对进程进行管理。但这样存在不少缺点(中文版本)。

PHP-FPM 配置起来很简单，但有一点比较有意思的是如何确定 Worker 的数量。PHP-FPM 作者 Andrei Nigmatulin 在新闻组里提到的小技巧如下：

1) 用 Linux top 命令观察 (这个方式比较土)
2) 用 'netstat -np | grep 127.0.0.1:9000' 收集数据。
设置  php-fpm.conf 中的 max_children 的数值使 等待的数量变为最小。

目前使用 PHP-FPM 还只是通过 Patch 方式，然后编译，期待能够早点并入正式的 PHP 代码中。当然，PHP 核心开发的那些大爷们也不知都在忙什么呢，莫非还在为 Unicode 较劲呢?

–EOF–

Tips : PHP-FPM on highload tips

此文作者:, 位于 Web 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Facebook 的 PHP 性能与扩展性

炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流，逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。

Cache 为 王

任何一个成功的站点都有一套最合适自己的 Cache 策略。

Facebook_Cache_Level.png

Note：这个层次图画的稍微有点问题，不是严格从上到下的。

The Alternative PHP Cache , APC

Facebook 平均每个用户每天要访问超过 50 个页面，PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层，Facebook 采用了 APC。

Lucas Nealan 的 PPT 举了一个例子，一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下，性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。

PHP_APC.png

Memcached 层

APC Cache 的是非用户相关的信息，而用户相关的数据 Cache 当然是在 Memcached 中。

Facebook 部署了超过 400 台 Memcached 服务器，超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码，包括 UDP 的支持和性能上的提升(性能提升超过 20%)。

程序 Profiling

Facebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目，这也是不可或缺，也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。

补充一下：语言的选择

为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: “Languages’s don’t Scale, Architecture Scale”。

从 80-20 的原则看，APC 和 Memcached 是最主要的。在这两个环节上下功夫，受益/开销比要大于另外几个环节。

(上面的图是从 Lucas Nealan 的文档截的，版权所有是他的)
–EOF–

PHP 与 Oracle DRCP

Oracle 对 PHP 的支持一直是不错的(只是国内好像 PHP + Oracle 的开发并不多)。 Oracle 11g 中的新特性数据库驻留连接池(Database Resident Connection Pool，DRCP) 对 PHP 应用进一步扩展带来了一种可能。

这个特性应该重点针对 PHP 应用的。PHP 不支持真正的多线程，非持久连接非常消耗 CPU 资源，扩展性也差；持久连接扩展性好了一点，但是又额外占用更多的内存资源(PHP 之父在几年前的一个 Step-by-Step 优化演示的文章中很形象的说明了连接开销对应用的影响)。DRCP 的出现能更好的缓解上述两个问题，其共享连接能跨 Apache 与中间件节点，但共享的连接是基于数据库用户的，比如 Scott 用户登录到 DB 上的所有连接间共享。

Oracle_DRCP.jpg

Oracle 官方披露的测试数据是，在 4 CPU Intel Xeon MP 2.80GHz 机器上，2GB RAM, 32bit RHEL 4. 支撑到 14000 个链接的时候，CPU 使用率在 65% 左右。这个…还是太惊人了，根据我找到的另外一份测试结果，看来要大打折扣才能有参考性。

–EOF–