本来是发在长微博的, 不过, 鉴于, 好久没更新博客了...... 就转过来, 凑个数吧, 大家凑合着看 🙂
白忙活了近2个小时,不吐不快:
一切要从今天下午5点左右说起, 调试一个扩展, 用valgrind(valgrind-3.8.1)做例行检查, 很不幸的valgrind报告invalid read:
最近我们的服务在升级php使用的libcurl, 期望新版本的libcurl支持毫秒级的超时, 从而可以更加精细的控制后端的接口超时, 从而提高整体响应时间.
但是, 我们却发现, 在我们的CentOS服务器上, 当你设置了小于1000ms的超时以后, curl不会发起任何请求, 而直接返回超时错误(Timeout reached 28).
原来, 这里面有一个坑, CURL默认的, 在Linux系统上, 如果使用了系统标准的DNS解析, 则会使用SIGALARM来提供控制域名解析超时的功能, 但是SIGALARM不支持小于1s的超时, 于是在libcurl 7.28.1的代码中...
这个PPT以前已经在微盘上分享过了, 今天突然想起来, 上传到了slideshare上, 顺便也在博客上留个纪念吧.
这个PPT介绍了过去一年我在微博的工作成果, 包括Yaf的改, 以及新东西Yar, Yac等
通过一系列的努力(整体方针是, 先提速, 降成本, 清晰架构, SOA), 我们让微博首页的响应时间下降了一倍多, 同时还降低了整体的成本.
首先, 太久不更新博客了, 容我先啰嗦几句.
我一直以为人总是会挤出时间写博客的, 但现在看来我错了. 博客很久不更新, 倒不是说没有内容可以分享. 而是这一年来确实忙了很多, 本身工作上的事情就很多, 业余时间也被PHP项目上的事情, Zend的事情填满. 再加上一些小感悟也都在微博上牢骚了... 所以....
Anyway, 很感谢各位经常来我博客的朋友, 不过我建议大家如果是提问的话, 不要在留言里, 有的时候会被博客当做SPAM, 有一些小问题, 可以来微博At我 @laruence
言归正传, 今天分享个前天刚刚做的小工具, 代码可以在我的github上找到: php-valgrind. 这个工具主要是为PHP脚本提供了可以在脚本中开启Valgrind(严格说是Callgrind)的Profile能力.
关于PHP的浮点数, 我之前写过一篇文章: 关于PHP浮点数你应该知道的(All ‘bogus’ about the float in PHP)
不过, 我当时遗漏了一点, 也就是对于如下的这个常见问题的回答:
<?php
$f = 0.58;
var_dump(intval($f * 100)); //为啥输出57
?>
为啥输出是57啊? PHP的bug么?
我相信有很多的同学有过这样的疑问, 因为光问我类似问题的人就很多, 更不用说bugs.php.net上经常有人问...
要搞明白这个原因, 首先我们要知道浮点数的表示
After Yaf, there comes another PHP framework in extension(在Yaf发布以后, 又出现了一个PHP扩展的框架 Phalcon): Phalcon.
then there raise a problem, which people have asked multi-times to me, that is , which one is the *fastest*(于是就出现一个问题, 不停的有人问, 到底Yaf和Phalcon哪个快, 因为他们都在他们的主页上宣称是最快的框架)? Yaf, or Phalcon. as they both declared they are the fastest(Yaf, Phalcon)
Yar(yet another RPC framework, 教主问我为啥都是Ya打头, 呵呵, 因为这样名字好起)是我在3个多月前, 为了解决一个实际的问题, 而开发的一个PHP扩展的, RPC框架, 和现有的RPC框架(xml-rpc, soap)不同, 这是一个轻量级的框架, 支持多种打包协议(msgpack, json, php), 并且最重要的一个特点是, 它是可并行化的..
with 84 Comments最近关于apc.include_once_override的去留, 我们做了几次讨论, 这个APC的配置项一直一来就没有被很好的实现过.
在这里, 我想和大家在此分享下, 这个问题的原因, 以及对我们的一些启示.
关于使用include还是include_once(以下,都包含require_once), 这个讨论很长了, 结论也一直有, 就是尽量使用include, 而不是include_once, 以前最多的理由的是, include_once需要查询一遍已加载的文件列表, 确认是否存在, 然后再加载.
诚然, 这个理由是对的, 不过, 我今天要说的, 是另外一个原因.
Yaf是我在俩年前写的一个PHP扩展的MVC框架. 开发Yaf的目的是为了解决使用框架带来的性能下降的经典矛盾.
最初要感谢百度的同仁们的信任, 以及当时各位老大的支持, 容许也敢于让我"试错", 才让Yaf顺利的度过了"没人敢用"的阶段, 大量的百度的新的产品基于Yaf开发, 让Yaf的稳定性得到了充分的验证, 也普遍的提高了PHP应用的执行效率.
而现在, Yaf的高性能又一次在微博的应用中得到了证明, 通过迁移框架到Yaf, 和一些其他优化手段, 我们成功的让新版微博的TPS提高了76%之多, 响应时间下降了近一半.
然而, 我也看到, 还有不少同学对Yaf有疑虑, 甚至有质疑, 有人认为"使用C写框架? 那不是回退到写CGI的时代了?", 于是我想我有必要写一篇文章, 详细介绍下我对Yaf的一些理解.
最早的时候, 我记得是去年我刚加入开发组的时候, 神仙同学曾经提过, 问我是否可以考虑为PHP实现yield. 我当时做过尝试, 但是最后发现需要大改zend executor, 而当时的我还没有那么大的魄力(因为我记得当时我的第一个RFC刚刚被拒绝)认为我能说服那么多人接受这个变动, 所以后来就不了了之了.
但, 现在Nikita Popov, 完整的实现了这个RFC: Generators, 并且已经提供了一个可用的实现, 目前这个RFC在投票阶段, 投票形式也比较乐观, 所以如果不出大问题, PHP5.5将会引入这一新特性.
我就这里为大家简单介绍下, 这个新特性.