让PHP程序员工作更高效.docx

让PHP程序员工作更高效的四大神奇做程序猿媛是一个苦逼的活，大周六地早起在技术群里招呼，看到没有啥人响应，说了一句，估计都没有醒，然后一位哥们抛过来，在加班 ！做 Web 开发更是一个苦逼的活，不像是做 iOS，搞定客户端，基本上就万事大吉了。做 Web 开发不仅仅是要做后端，前端也需要了解和熟悉！做前后端通吃的 DevOps 全栈工程师绝对是最苦逼的活，不但需要做开发，而且还要了解运维、优化，不会运维的工程师绝对不是一个好架构师！但所幸的事，一个优秀的工程师尽管很忙，尽管要熟悉前后端、系统、运营、优化，但是在他的工具箱里，放着一大堆工具，让这种生活变得不那么苦逼。这里就介绍四个让我们 DevOps 生活变得美好的神器。分别是 Xdebug、XHProf 、 OneAPM 和 SocketLog。Xdebug作为开发人员，睡得最踏实的事是对自己写的代码了如指掌，无论是从功能层面，还是性能层面。而做 Web PHP 开发，比较棘手的一件事情就是代码的调试。作为脚本语言，在远程服务器端运行，客户端生成的全是 HTML 代码，一般认为我们无法准确地调试运行的情况，更不要说单步调试、变量监控等事情了。其实这是有误解的，有一个 PHP 扩展 Xdebug 能让方便地让我们调试远程服务器上运行的代码。方法很简单，从 Xdebug 下载最新版的源代码。 wget 解压：tar zxvf xdebug-2.3.3.tgzcd xdebug-2.3.3 phpize./configure with-php-config=/usr/bin/php-configmakemake install 再增加相应的配置到 php.ini ，需要注意有两点：1. xdebug 是 zend_extension2. 端口默认是 9000，和 php-fpm 的缺省端口冲突，所以这里换用 9100xdebugzend_extension=/usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.soxdebug.remote_enable=onxdebug.remote_handler=dbgpxdebug.remote_host=localhostxdebug.remote_port=9100 这样就装好了，就是如此简单，下面我们可以开始使用了。以 ThinkPHP 应用开发做例子吧。ThinkPHP 典型的单入口应用，调用层次相对复杂。所以想要了解调用堆栈还是比较麻烦的。要想得到某一行的调用堆栈，可以使用 PHP 自带的 debug_backtrace 函数可以获得，但是不怎么形象，返回来一个数组而已。而 Xdebug 就能让这一切可视化起来。配合 Xdebug 使用的是 Netbeans 自带的调试工具。首先通过首选项修改了一下 PHP 调试的端口，从9000改成9100，其他不用动。注意 在第一行停止 是选上的，这将在 PHP 程序调试时，运行到第一行 PHP 代码时停止，在 ThinkPHP 中，即入口文件 index.php 的第一行停止。在本例中，笔者做了一个租车管理系统的示例，项目名为 zuches 。将代码部署在 http:/localhost/zuches 能访问的地方，索引文件是 index.php。由于 index.php 是入口文件，所以在 index.php 上点击右键，选择调试。然后 Netbeans 自动打开了如下地址，进入调试状态 ： http:/localhost/zuches/index.php?XDEBUG_SESSION_START=netbeans-xdebug 同时运行位置指示停留到了 index.php 的第一行。如下：点击继续运行，由于在 IndexController.class.php 的 index 方法中加上了断点，所以位置指示又停留在了相应的断点处。这个时候，我们可以查看中断时候的调用堆栈和变量了。通过堆栈可以方便地定位到各定位的类和相应方法。各种变量，无论是局部变量和实例属性，无论是 cookie，还是提交数据，都能在变量表中看到，一目了然。总之，Xdebug 让我们即使做的是服务器端页面和 API 开发，也可以像桌面应用开发一样，调试每一行代码了。Xdebug 除了使用来进行单步调试之外，还能收集请求中的执行日志，记录每一个函数的执行过程。这些日志可以用 wincachegrind 等工具进行分析，看到函数的调用栈和所花的时间。这里不再赘述，我们也不是很推荐，因为 XHProf 在这块要轻量级和强大的多，不用如此费劲地下载日志，分析日志。XHProf如前文所述，对于 PHP 中函数调用栈和性能分析，XHProf 将 Xdebug 开的先河继承并发扬光大。XHProf 也是 PHP 扩展，不过不建议从 /package/xhprof 上下载，版本已有近2年没有更新了，最好从 /phacility/xhprof 上下载。下载编译配置和使用过程都很简单。配置只需要加上如下两行： xhprof extension=/usr/lib/php/extensions/no-debug-non-zts-20121212/xhprof.so然后将要相应的 XHProf 代码配置到需要监控的页面中，即可以获得整个页面的执行中，各函数的调用报表。XHProf 提供了示例，配置成功运行如下：如何看到上面图中的效果呢？将 examples 、 xhprof_html 、 xhprof_lib 三个目录放到浏览器能访问到的地方，比如 localhost 的主目录内。修改 examples/sample.php 中的 换成 如： localhost/xhprof_html/ 。即可。然后访问 http:/localhost/examples/sample.php 即可以得到输出结果如下：从 examples/sample.php 中可以看到，对于页面的监测分析，在页面顶部使用 xhprof_enable 开始，而性能的分析的结束，则是在页面底部使用 xhprof_disable 结束 。这样每次监控，都需要增加一段代码，所以为了规范起见。对 XHProf 相关的操作进行了封装。继续采用上例 ThinkPHP 版租车系统的例子，看看如何集成 XHProf 分析。首先将对 XHProf 的操作封装成了一个类。save_run($xhprof_data, $profiler_namespace); $profiler_url = sprintf(http:/ . $_SERVERHTTP_HOST . /xhprof_html/index.php? run=%s&source=%s, $run_id, $profiler_namespace); echo . Profiler output; 在这个封装的类中，首先检测了 xhprof_enable 函数是否存在，这可以用于判断是否成功安装配置了 xhprof 扩展。其次设置了参数，特别值得一提的是使用函数 register_shutdown_function 来注册一个操作，这个操作在页面结束之前，会自动运行。这样，在分析页面性能之时，只需要在 ThinkPHP 应用的 index.php 上加上两行，即可以了。比如：require_once xhprof.php; XHProf:init(zuches); 运行后，得到如下效果：并且每一个页面，都有这样的输出。点击Profiler output即得到了报表。在本例中，可以看到最后的集成方法，运行时间超过了2 S，是值得关注并优化了。从报表中，可以首先看到各个方法或者函数的调用次数，运行时间，以及可以层层点进去看到父子层级的调用关系 。需要注意的是，在线上，如上使用 XHProf 要慎重，即使打开，也要有限制条件地打开，比如当前用户是某些调试开发者用户时才打开。否则，普通用户看到这样的输出，则不明所以，给用户带来困惑，当 然，我们也可以不输出，而将数据直接存储，在后台系统中查看，这样用户就感受不到了。有一个工具，可以完全消除这些纠结。那就是 OneAPM ，在第四部分我们再介绍。SocketLog作为程序员，除了新功能开发之外，最常见的一个工作就是查错，尤其是远程用户的查错，还是一个很痛苦的过程。当前又加上了微信开发，API 开发等操作。对于微信内、API 由远程用户所调用的时候，情况多变，查错也更加地麻烦。这个时候，我们的第三个神器登场了。那就是 SocketLog。SocketLog 是国内知名 PHP 开发者罗飞的作品，罗飞是 ThinkPHP 的核心开发者，也是优才学院全栈工程师主力讲师。现任三生社群 CTO。SocketLog 的 github 地址为： /luofei614/SocketLog ，在项目的主页上，详细地介绍了用法和所用的技术。这里简单地汇总讲解一下。SocketLog 的使用，主要要分成三个步骤，第一步是安装 Chrome 插件。可以从 github 下载的安装包中去安装，或者可以从 Chrome 应用商店下载。第二步是需要启动 Socket 服务，Socket 服务是 WebSocket 协议的，早期版本是 PHP 编写的服务器，新的版本已经使用 Node.js 来实现了。启动方法很简单，进入解压后的目录。执行 node server/index.js 即可。安装好插件之后，就在 Chrome 上看到如下图标。灰色表示没有连接上。同时启动了服务器，做好设置，就会看到图标变成蓝色了。需要注意的是，尽管我们这里监听地址配置成了本地地址，其实也可以配置远程地址。不过远程地址的话记得打开服务器上的防火墙，因为一般1229端口在防火墙中是关闭的。SocketLog 的原理，是在服务器端，往 WebSocket 服务器上写数据，作为客户端的 Chrome 插件，即能收到数据。所以不管是远程 API 调用，还是网页访问，只要在程序中往这个 WebSocket 服务器写了数据，只要监听了这个 Websocket 服务的客户端都能收到相应的调试日志。第三步是埋代码。使用方法也很简单。比如我们在上面的 ThinkPHP 的 index.php 加入两行代码。会看到如下输出 。然后我们在其他终端上也访问一下这台机器的这个页面地址，看看是否能得到输出呢？开始没有任何输出效果。因为缺省情况下是不记录普通用户所调用的 slog 的。在 slog 之上的语句加上这一行，就有了。slog(array(force_client_id=test),set_config); Test 这个插件的用户，收到了所有的 slog 消息。如下图所示：并且这种输出 ，无论是别的用户触发，而还后台服务程序，均可以输出 。所以非常地方便，开发人员在自己的机器上就收集到了想要收集的用户所触发的调试信息。然后为了体现对 SQL 语句的监听。我们在 ThinkPHP/Library/Think/Db/Driver.class.php 的第1139行加上 slog($str) ，然后再访问页面，就得到了如下输出 ，可见实现了对 SQL 日志的监控。SocketLog 的功能看起来虽然简单，但是却非常有用、好用，是不可多得的开发神器。有关 SocketLog 的更多介绍和使用说明，建议现在就立刻下载，并且进入 github 主页好好地研究吧！OneAPM从上面的使用来看，SocketLog 和 XHProf 都有两个不足之处，一是需要埋代码，二是只是基于单独一个页面会话的。而 OneAPM 相对来讲，就更强大了，可以理解为云端 SaaS 版的 XHProf 和更强大的 SocketLog。不过有着更为强大的优势。比如:OneAPM 的 PHP 探针，安装完成之后，并不需要在代码中埋入任何代码。在数据收集的过程中，不需要开发和运维的参与，探针全自动收集，并提交到远程服务器。由于数据累积，所以支持历史报表，以及比 XHProf 和 SocketLog 更丰富的功能。PHP 只是 OneAPM 所支持的一种语言，它可以支持多种语言，HTML5、 iOS 、 Android 、 Java 、 .NET 、 python 、 Node.js 、 PHP 、 ruby 等。OneAPM 的安装过程也比较简单，不过由于是 SaaS 服务，所以得上官网注册一个账号。登录了之后，在应用程序里，点击添加，再选中 PHP，就进入了安装探针的说明。分为如下几步：1. 获取授权编号OneAPM 授权凭证，用于配置和身份识别。2. 下载 OneAPM PHP agent 安装程序3. 解压 OneAPM PHP Agenttar -xzf OneAPM_php_Agent_2.3.11.tar.gz 4. 安装 OneAPM PHP Agent定位路径至您的安装包所在文件夹cd oneapm-php5-linux-install-script执行安装命令sudo ./oneapm-install install5. 输入 License Key请点击步骤1中的生成授权编号按钮成功安装，界面如下：若出现以下信息，则代表安装成功。OneAPM is now installed on your system. Congratulations! 当页面出现以下提示时，启动 DaemonAnd then start php-agent in /usr/bin/oneapm-daemon 运行以下指令来启动 Daemonsudo /usr/bin/oneapm-daemon 重启 Apache 或你使用的 web 调度程序 如 php-fpm 6. 静候5分钟，开启 OneAPM 之旅静候5分钟，等待应用程序向 OneAPM 发送应用程序性能数据，即可开始使用 OneAPM 应用性能管理。OneAPM 收集的数据很丰富。将收集的响应时间数据，分为四个大块:Web 事务，就是页面业务逻辑本身数据库，数据库的连接和数据读取错误统计，对所有类型的错误做了归类统计外部服务，即外部 API 等的设备以笔者的站点为例，12小时的数据如下图：从上面这个图，我们看到响应时间，慢的达到了600 ms 以上，那是什么导致的呢？我们可以分别查看：可见 Web 事务比较稳定，可以比较清楚地看到平均的响应时间在 50ms-75ms之间。数据库响应时间也很短，在几 ms 这个级别。而外部服务就明显在几百 ms 这个级别，还有的高达 600 ms 。不说别的，就通过这简单的报表，从目前看，就可以定位到，想要做优化，从外部服务的响应时间上下手优化，带来的效果是最大的。下面我们再来看看三个细化一层的报表 ，在 Web 事务统计中，尽管平均数很低，但是也列出了响应时间最长的5个请求。如下：从上面的数据可以看出，响