各开源框架使用与设计总结（二）

原文详见：http://www.ucai.cn/blogdetail/7032?mid=1&f=12

 可以在线运行查看效果哦!     

 

5.4、zephir高效开发模块

 

好的，讲到这里，衍生出一个小话题，就是开发模块。

在PHP里，开发模块，是一个很痛苦的过程。因为C语言，大家都知道，是出了名的难学的，值得高兴的是，也是Phalcon这个团队的童鞋们，也为我们准备了一个高效的开发模块的语言，称之为zephir。正因为扩展如此难以开发，但是扩展又是如此高效，所以我们要用高效的方式来开发扩展。

 

git clone https://github.com/phalcon/zephir.git

cd zephir/

mv zephir /usr/local/

 

扫描二维码关注公众号，回复： 561644 查看本文章

然后就可以开发模块了，我们使用

zephir init gkk

生成模块的框架，

然后 cd gkk/gkk

编写 hello.zep

 

 

namespace Gkk;
 
/**
 * This is a sample class
 */
class Welcome
{
    /**
     * This is a sample method
     */
    public function welcome()
    {
        echo "你们好!参加优才网公开课的同学们!";
    }
 
    public function say()
    {
        echo "今天是优才网第三十三讲公开课了!";
    }
 
 
}

 

 

 

然后再返回

 

zephir compile
zephir build

 

 

 

然后在 php.ini 中配置

extension=gkk.so

 

通过 php –m 可以看到相应的模块。再编写

 

test.php
<?php
 
$t = new Gkk\Welcome();
$t->say();
echo "\n";
?>

 

 

 

就能看到相应的输出。

 

 5.5、各框架性能总结

好的，有关两个用C开发的框架和相关内容我们就介绍到这里。下面我们来总结一下框架，以及做一些性能评测。

首先来看一下性能评测报告，这是一个专门测框架的github项目出的数据，

 博客在这里，

•https://github.com/eryx/php-framework-benchmark

 

从上面的图可以看到，两个用C编写的框架，性能还是相当可观的。Yaf比Phalcon性能更强，也不奇怪。因为结构更为简单，模块更少。同时也发现，像zend framework这样的框架，是不能轻易在一个大众的互联网产品中使用的，尽管代码写得不错，但是效率太低了，有木有！

 

5.6、PHP的重写

在评测之前，大家记起来了没有，我们上面讲了六点，其中有一点是什么？重写PHP！

 

那就看看，哪些业界人士，在PHP重写的路子上做了非常激动人心的尝试。

刚才讲了，谁最有动力？

有两个方面的人有动力，一个是PHP最大的使用者，一个是PHP官方。最大的使用者，他对PHP的提升，能大幅度地减少资源的占用，一个百分之几的优化可能就是成百上千台设备的节省。而后者，则要想到如果PHP本身效率提升不上去，在未来的发展过程中，很容易出现转折，尽管现在还是非常火的。

 

所有从官方，就有了，PHPng，这个我没有安装过，有兴趣的同学，可以自己去折腾，https://wiki.php.net/phpng值得一提的是，咱们国内的鸟哥是这个项目的主要参与者之一。Yaf也是他的作品。而另外一个，则是Facebook主导的，HHVM，其前身是HipHop， 当时的思路是把PHP全部编译成C++程序，在上线的过程中，上线的是一个二进制包，非常不灵活，修改代码，需要发包才能生效。如果出现故障，会有灾难性的影响。所以演进到现在成了HHVM，全称是HipHop Virtual Machine。

现在的模式，简单了讲就是可以做为FastCGI 的运行容器。大家安装过LNMP的同学就知道，在Nginx的后端，也就是说Nginx的配置中，通过

fastcgi_pass  这个配置指向了实际运行PHP的FastCGI 运行容器，PHP自带的是PHP-FPM（FastCGI Process Manager），而HHVM就是可以一定程度上无缝地替换掉，FPM，比如你kill掉FPM进程，通过

 

hhvm --mode server -vServer.Type=fastcgi -vServer.Port=9000 &

 

来启动HHVM。都不需要修改nginx 配置。就可以访问了。

但是性能一定程度上，大有提升。

 

这枚神器有如下特点：

•当然不是小团队能玩的

•与PHP 5.2引擎+APC相比，可以处理的Web请求吞吐量增加了9倍，而内存消耗减少了5倍。

•如无特殊模块，可以无缝替换 php-fpm（除了极少数兼容问题）

 

•1、优点

–FB出品

–强大到令你吃惊，数十倍的性能提升

–已经趋于稳定，无缝替换 PHP-FPM

 

•2、缺点

–还不是很稳定

–模块需要迁移

 

六、各项实践，性能评测

下面进入性能评测，评测我们相对就比较快速一些。直接用ab命令，来测试上面的所提及的一些改进。

以下评测，所有测试页面，均为：http://hjvote.app.ucai.cn/index.php命令行为：

ab -c 20 -n 1000 http://hjvote.app.ucai.cn/index.php

 

6.1 、冷启动

1、冷启动，比如我新启动的php-fpm，关掉opcache，关掉xhprof

 

Concurrency Level:      20
Time taken for tests:   4.981 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      478000 bytes
HTML transferred:       109000 bytes
Requests per second:    200.78 [#/sec] (mean)
Time per request:       99.612 [ms] (mean)
Time per request:       4.981 [ms] (mean, across all concurrent requests)
Transfer rate:          93.72 [Kbytes/sec] received
 

 

 

6.2、第二次

2、第二次，条件同上。

 

 

Concurrency Level:      20
Time taken for tests:   4.537 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      478000 bytes
HTML transferred:       109000 bytes
Requests per second:    220.42 [#/sec] (mean)
Time per request:       90.736 [ms] (mean)
Time per request:       4.537 [ms] (mean, across all concurrent requests)
Transfer rate:          102.89 [Kbytes/sec] received

 

 

 

6.3、打开opcache第一次

 

Concurrency Level:      20
Time taken for tests:   1.591 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      478000 bytes
HTML transferred:       109000 bytes
Requests per second:    628.67 [#/sec] (mean)
Time per request:       31.813 [ms] (mean)
Time per request:       1.591 [ms] (mean, across all concurrent requests)
Transfer rate:          293.46 [Kbytes/sec] received
 

  6.4、第二次，条件同上

 

Concurrency Level:      20
Time taken for tests:   1.254 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      478000 bytes
HTML transferred:       109000 bytes
Requests per second:    797.70 [#/sec] (mean)
Time per request:       25.072 [ms] (mean)
Time per request:       1.254 [ms] (mean, across all concurrent requests)
Transfer rate:          372.36 [Kbytes/sec] received
 

  6.5、对比再打开xhprof

 

Concurrency Level:      20
Time taken for tests:   1.254 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      478000 bytes
HTML transferred:       109000 bytes
Requests per second:    797.44 [#/sec] (mean)
Time per request:       25.080 [ms] (mean)
Time per request:       1.254 [ms] (mean, across all concurrent requests)
Transfer rate:          372.24 [Kbytes/sec] received

 

 

 

6.6、打开XHprof，关掉Opcache

 对于这个简单的页面，没有明显恶化，我们去掉Opcache，打开xhprof

 

Concurrency Level:      20
Time taken for tests:   12.103 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      595000 bytes
HTML transferred:       226000 bytes
Requests per second:    82.62 [#/sec] (mean)
Time per request:       242.065 [ms] (mean)
Time per request:       12.103 [ms] (mean, across all concurrent requests)
Transfer rate:          48.01 [Kbytes/sec] received

 

 

 

6.7、第二次、条件同上

 

Concurrency Level:      20
Time taken for tests:   9.298 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      595000 bytes
HTML transferred:       226000 bytes
Requests per second:    107.55 [#/sec] (mean)
Time per request:       185.952 [ms] (mean)
Time per request:       9.298 [ms] (mean, across all concurrent requests)
Transfer rate:          62.50 [Kbytes/sec] received
 

 

 

在没有opcache的情况下，XHProf的加入，导致用户急剧变慢。

 

6.8、关掉xhprof  HHVM第一次

 

Concurrency Level:      20
Time taken for tests:   1.142 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      521000 bytes
HTML transferred:       109000 bytes
Requests per second:    875.84 [#/sec] (mean)
Time per request:       22.835 [ms] (mean)
Time per request:       1.142 [ms] (mean, across all concurrent requests)
Transfer rate:          445.62 [Kbytes/sec] received

 

 

 6.9、第二次，条件同上

 

Concurrency Level:      20
Time taken for tests:   0.852 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      521000 bytes
HTML transferred:       109000 bytes
Requests per second:    1173.42 [#/sec] (mean)
Time per request:       17.044 [ms] (mean)
Time per request:       0.852 [ms] (mean, across all concurrent requests)
Transfer rate:          597.03 [Kbytes/sec] received
 

 

 

 

什么感觉？这种数字的差距是不是可以用震撼来形容？通过评测对比，我们对于opcache、hhvm和一般php-fpm性能心里也就有数了。同时也发现，在页面上开启XHProf，会导致网页性能急剧下降，所以不要在生产环境对多人开启XHProf。或者会带来非常不好的用户体验。

 

 

七、自有框架的设计

好的，看完了性能评测，我们来过了一下如果设计一个自有的框架需要哪些元素，或者说需要哪些内容。

 

1、首先对目录结构进行一个划分，确定目录层次结构

–app    命令行应用

–data   存放数据上传

–lib 库函数

–template  模板

–conf   各种配置

–doc    文档，SQL

–log     日志

–test    测试代码

–ctemplate 编译后的模板

–htdocs     Web主目录

 

大家能看到，htdocs 同其他目录，比如 doc、app目录为什么要并列？这是安全性的考虑，想一想，否则的话，你的表定义被人下走了。你的后台程序，可能会被用户执行。

 

2、其次来看一下类的层次结构。

下图是应用程序各个类的分层。

 最基层的应用程序类，其实就是一个骨架。包括了getParam(取得参数，无论命令行，还是Web访问，都需要有参数分析)。checkParam（参数检测）、checkAuth(权限检测，比如是否是需要登录的一个页面)、outputPage等这些方法，全是空方话，但是由一个run方法串起来。如下：

 

 

public function run()
      {
          
           $this->getPara();
 
           $this->checkPara();
          
           $this->checkAuth();
 
           $this->main();
          
           $this->outputPage();
 
           $this->exitApp();
      }
 

 

 

 

应用程序基类DCore_BaseApp.php的子类又分为三个，一个负责命令行程序的处理DCore_ConsoleApp.php，另外一个负责像移动应用、开放平台Api之类的数据处理DCore_ApiApp.php ,而第三个，则是DCore_WebApp.php, 我们所在浏览器上所访问的应用，由这个应用程序类派生出来页面类。而DCore_AdminApp.php，是管理后台应用程序类的基类。因为后端一般有不一样的权限认证机制。这样也是为了把前后台的应用程序类区分得更加清楚。

 

这样可以看到，整体结构非常清晰。

 

好，那最后我们再来看一下，需要编写哪些类库。

在我们的框架中，编写了这些。

•1、常用工具函数库

实现字符串的常用操作封装，比如中文取字串，繁简转换、编码转换

 

•2、模板引擎

可以简化为包含PHP，在我们自己开发的这个框架中，支持了模板编译，其实模板编译很简单，就是将一些特定的语法，换成PHP代码，然后还是包含PHP

 

•3、路由控制，静态化

用户可以将路径改成搜索引擎更友好的路径，程序也能解析正确。

 

•4、后端数据请求控制

用于对后端一些公用操作的封装，比如数据库，比如Memcached，这样的封装带来的好处是，如果一旦发生升级或者替换的时候，修改的代码相对最少。比如你不用到处去改mysql_query，只需要修改当前这个库文件即可以了。

 

八、总结

好的，今天的课程就到这里。总结一下，我们讲了如下几点：

1、5月课程尤其是5月份框架课程的总结。总结了框架与架构的区别。

2、站在PHP框架之外，看框架，看框架的共同特征与功用。

3、以PHP框架为例，讲框架所不能解决或者带来的问题。

4、由于框架所带来的问题，以性能、可扩展问题，相对严重，所以分析PHP性能 的改造方向，总结了六大点。

5、分别演示了这六大点的改进实践。包括Yaf、Phalcon框架介绍，zephir的使用，以及HHVM。

6、汇总六大点的改进，并做了相关的性能评测。能看到，使用不同的技术差别巨大，所以我们要在稳定可靠的情况下，尽可能采用最好的技术。

7、最后讲解了开发一个自有框架，一般都是一个什么样的思路。