php的异步http请求类
这篇讲的是作者如何解决PHP中同步HTTP请求阻塞程序的问题。基于之前对libevent扩展的探索，作者构建了一个异步的HTTP请求类，核心思路是利用事件循环机制来处理网络I/O。 作者没有选择传统的多进程或cURL轮询，而是直接深入底层，利用libevent的事件驱动模型。这意味着程序可以非阻塞地发起多个HTTP请求，并在等待网络响应的同时处理其他逻辑，显著提升了并发性能。这种实现方式在需要批量抓取数据或调用多个API的场景下尤其有效。 文章的巧妙之处在于，作者将复杂的底层事件循环封装成了简洁易用的类接口，让其他开发者也能相对轻松地在自己的PHP项目中实现异步操作。对于受困于同步请求性能瓶颈的开发者而言，这提供了一个实用且思路清晰的解决方案。
用Flash理跨域上传或异步请求不能传Cookie的解决方案
这篇讲的是 Flash 时代一个经典痛点：当你用 Flash 上传文件或发起异步请求时，因为 Flash 播放器无法直接读取和携带当前浏览器的 Cookie，导致服务器端的 PHP Session 无法识别用户身份，请求就“裸奔”了，身份验证直接失效。 根因在于 Flash 运行在独立沙盒，与浏览器 JS 环境隔离，因此无法复用浏览器已经管理好的 Cookie。文章没有停留在抱怨问题，而是直给 PHP 环境下的轻巧解法。核心思路是绕过 Flash 的限制，采用“参数透传”的方式，在 Flash 发出的请求参数里，显式地带上 Session ID。服务器端 PHP 只需从这个参数里取出 ID，手动绑定到会话上，就能完成身份识别。 本质上，这是一种在客户端可控的情况下，对 Cookie 机制的模拟和补充。虽然现代 Web 技术（如 CORS）已让此问题淡出视野，但文章里展示的“寻找替代通道传递关键标识”这一解决思路，对于理解早期 Web 开发的约束和变通智慧，依然有其价值。
TCP Fast Open by Google 浅析
这篇讲的是Google即将在ACM CoNEXT会议上发表的一项关于降低Web应用响应延迟的工作。它聚焦于改进TCP协议，通过一种名为“TCP Fast Open”的技术，允许客户端在建立连接的三次握手阶段就携带应用数据发送，从而争取省去一次往返时延（RTT）。 文章提到，虽然论文刚刚发布，但相关的RFC草案其实早在2011年3月就已提交给IETF，并在近期进行了更新。作者从这个协议草案的演进出发，分析了TFO技术的基本原理：服务器可以向支持该特性的客户端返回一个加密的Cookie，后续该客户端在发起新连接时，就可以在SYN包中直接带上首部请求数据（如HTTP GET），服务器在验证Cookie有效后即可立即处理该请求，无需等待握手完成。 这意味着对于频繁访问的网站，页面加载的首字节时间能够得到显著改善，特别是在高延迟或易丢包的网络环境下。从草案的持续更新来看，这项技术正朝着标准化稳步推进，可能会成为未来提升Web性能的一个基础性优化。
PHP原理之内存管理中难懂的几个点
这篇深入剖析了PHP核心Zend内存管理器（Zend MM）的底层实现，着重解析了那些从源码中也未必容易看懂的精巧设计。 文章首先区分了Zend MM管理的两类内存：追求高性能的小块内存与追求稳妥的大块内存。核心亮点在于作者对关键数据结构的解读：例如，为节省内存，free_buckets数组并未分配完整的空闲块结构体，而是巧妙复用了内存，只使用链表指针部分。又如，large_free_buckets被设计成一种结合了双向链表与二叉键树的混合结构——它将内存大小的二进制位作为键，实现了内存块的快速分类与定位查找，其查找逻辑非常独特。 值得注意的是，作者明确指出诸如TIPI等既有资料在此部分存在错误，并对bitmap索引计算、rest_buckets用途等细节进行了澄清和纠正。对于PHP扩展开发者或需要深入理解底层行为的工程师来说，这些辨析极具参考价值。文章揭示了PHP内存管理在高性能与低浪费之间权衡的诸多“小聪明”。
PHP5.4新特性-解引用实例化
这篇讲的是PHP 5.4引入的一个语法糖——解引用实例化。作者从一个简单的代码报错切入，展示了在旧版本中，直接对一个实例化结果（比如 `(new Foo())->bar()` ）调用方法会引发语法错误，迫使开发者必须先将对象赋值给一个临时变量。 文章的核心对比点在于PHP 5.4前后的写法差异。新特性允许开发者直接对 `new` 关键字创建的对象实例进行方法调用或属性访问，代码从繁琐的临时变量赋值变得一气呵成。这不仅提升了代码的简洁性和可读性，在某些需要临时创建对象并立即调用其方法的场景（如作为函数参数）下，也避免了不必要的变量声明，让逻辑表达更直接。 这个特性的引入，本质上是为常见的链式操作和短生命周期对象使用提供了更地道的语法支持，减少了模板代码，让PHP的面向对象编程体验更加流畅。对于从PHP 5.3及更早版本迁移过来的开发者来说，了解这一变化能写出更现代、更简洁的代码。
Linux下pipe使用注意事项
这篇讲的是Linux管道（pipe）使用中一个容易被忽略的性能陷阱。作者从日常开发中广泛使用的pipe出发，点出一个具体细节：由于Unix将一切视为文件，每次读取pipe时都会更新其访问时间（last access time）。这个时间戳对大多数应用场景毫无意义，但在高频使用的管道中，更新操作却会带来意想不到的开销。 文章指出，在pipe被密集使用的场景下，为设置访问时间而产生的系统开销，其规模甚至可能超过pipe本身的读写开销。这并非功能问题，而是一个纯粹的性能损耗点，尤其在高并发的服务器程序线程间通信中，累积效应会十分明显。对于追求极致性能的系统开发者而言，这个细节值得关注。
微博应用那点事
这位作者从新浪微博开放API开始，陆续开发了12个应用，累计用户数达到40至50万。文章正是基于这长达一年半的实战经历，对在微博平台做应用的得失进行了一次系统性的复盘。 内容聚焦于作者个人在开发、运营这些应用过程中的具体经验与教训。虽然摘要里并未罗列每条教训，但从标题“那点事”和作者积累的体量来看，其中很可能涵盖了从技术实现、用户增长到产品运营的多个层面。文章试图将这段较长周期内分散的实践，提炼成可供其他开发者参考的、更具普遍性的认知。 对于有志于在开放平台进行应用开发的读者，这篇文章的价值或许在于它并非纸上谈兵，而是源于大量真实项目沉淀后，对成功路径与常见陷阱的直观总结。
关于php的libevent扩展的应用
这篇讲的是 PHP 的一个高性能扩展——libevent。作者并非停留在理论介绍，而是直接分享了自己用它实现 Thrift Socket Server 的实战经验。Libevent 本身是一个用 C 写的事件驱动库，性能很高，而这个 PHP 扩展正是将其核心能力带给了 PHP 开发者。 作者在一年前的尝试中，已经验证了它在构建非阻塞服务端方面的潜力。他特别指出，这个扩展的价值远不止于此，完全可以用于开发聊天服务器、实时推送系统，甚至是类似 Node.js 的异步任务处理后端。文章从一个具体的实现案例出发，引出了对 PHP 在 I/O 密集型场景下性能边界的探讨。 对于想突破传统 PHP 同步阻塞模型、探索高并发服务端可能性的开发者来说，这篇文章提供了一个扎实的起点和清晰的思路。它不仅展示了 libevent 能做什么，更激发了对 “PHP 还能做什么” 的思考。
API设计新思维：用流畅接口构造内部DSL
这篇讲的是如何让API设计突破传统思维的局限，探索一种更贴近领域语言、更具表达力的全新方式。作者从实际开发中遇到的痛点出发——传统的API调用往往显得生硬、可读性差，尤其在构建复杂业务逻辑时，代码容易与领域知识脱节。 文章提出的核心方案，是利用流畅接口（Fluent Interface）模式来构造内部的领域特定语言（Internal DSL）。具体来说，通过精心设计的方法链和上下文传递，让API的调用序列本身就能形成一段近乎自然语言的表达。例如，不再是枯燥的函数调用堆砌，而是写出类似“创建用户，设置姓名，关联部门，并保存”这样连贯的指令流。 作者通过对比传统API与流畅接口的代码示例，清晰地展示了后者在可读性、可维护性和业务语义表达上的显著优势。这种设计不仅让代码自身成为了更好的文档，也使得封装复杂操作、减少认知负担成为可能。文章最终落脚于：好的API不应只是功能的暴露，更应是与开发者思维对齐的对话界面，而流畅接口正是实现这一目标的关键工具之一。
Yaf的性能对比测试
这篇讲的是Yaf框架的性能基准测试，作者从自己长期“偷懒”没做横向对比切入，终于补上了这块空白。文章将Yaf与其他主流PHP框架放在相同环境下进行跑分，核心对比集中在启动速度、内存占用和请求处理效率这几个关键指标上。通过具体的测试数据可以看到，Yaf在轻量级场景下展现出显著优势，其C扩展实现的底层设计让它在启动开销上远低于纯PHP框架；但在复杂业务逻辑或需要大量ORM操作的场景中，差异则会缩小。作者也指出，性能并非唯一选型标准，Yaf更适合对吞吐量有极致要求、且团队具备一定C语言调试能力的API网关或微服务项目，而功能丰富的全栈框架可能更适合快速迭代的Web应用。这种基于实测的对比，为技术选型提供了直接的数据参考。
保持简单----纪念丹尼斯o里奇（Dennis Ritchie）
这篇文章是作者受财新网之邀，为纪念刚离世的计算机大师丹尼斯·里奇所写。文章没有罗列其作为C语言和Unix创造者的丰功伟绩，而是抓住了里奇一生所践行的核心编程哲学——“保持简单”。 作者从里奇那些看似简洁甚至“简陋”的设计入手，阐述了这种简单并非简陋，而是一种深刻的洞察力与工程上的克制。文中探讨了里奇如何用最少的元素构建出强大而灵活的系统，以及这种哲学如何深刻影响了整个现代软件世界的根基。它提醒我们，在追求功能与炫技的时代，真正的智慧往往体现在对复杂性的有效驯服与舍弃上。 这篇文章更像是一次对技术初心的回望，让读者在缅怀大师的同时，重新思考自己编码与设计时的根本立场。
Postmark的邮件代发服务
这篇讲的是作者如何应对邮件发送中的性能瓶颈。以往，许多开发者依赖免费邮箱的SMTP功能来处理邮件，但这种方法的弊端日益凸显：发送过程常有延迟，每日发送数量被限制在50
【外刊IT评论网】关于node.js语言的讨论
这篇讲的是Node.js被调侃为"Node on nails"（服务器上的Node）背后的技术现实与常见误解。作者并没有从语法细节入手，而是直接切入其核心运行模型——单线程事件循环。 文章剖析了Node.js如何通过非阻塞I/O处理高并发请求，同时也坦率指出其瓶颈所在：一旦遭遇CPU密集型计算，单线程模型会立刻成为性能的"钉子"。作者用具体场景说明，比如图像处理或加密操作，这类任务会阻塞整个事件循环，拖慢所有请求的响应。 核心观点在于，Node.js的威力与其限制同源。它天生适合I/O密集型的网络应用，能用较少资源支撑惊人吞吐量；但若用错地方，比如硬扛重计算任务，其表现反而不如传统多线程语言。这篇讨论为开发者提供了清晰的选型边界：理解工具的特性，才能把它用在真正合适的地方。
SteveY对Amazon和Google平台的长篇大论
这篇文章讲的是前亚马逊员工、现任谷歌工程师Steve Yegge的一次“醉酒误操作”。他原本打算在Google+内部分享对Amazon和Google平台的深度看法，却意外将帖子设为公开，引发了一场技术圈热议。文章虽然很快被删除，但早已被互联网备份并广泛流传。 作者的核心观点非常犀利。他认为亚马逊的内部平台能力（他称之为“可编程基础设施”）异常强大，允许团队像搭乐高一样快速构建复杂服务；而谷歌虽然技术卓越，却过于聚焦于面向消费者的产品，在打造统一、开放的内部平台方面有所欠缺。这导致了两家公司截然不同的内部开发体验和效率。 更有趣的是事件后续：Steve后来解释说文章写于深夜酒后，观点主观且极端，并向公司公关表示了感谢。但这并未削弱文章的冲击力，反而让这次“意外泄露”成为了观察两大科技巨头平台战略差异的一个经典案例。它提醒我们，有时最真实的见解往往诞生于非正式场合，而公司文化和内部工具的设计，对创新速度有着决定性的影响。
三元式(ternary)性能优化
这篇讲的是PHP语言中三元式运算符性能优化的故事。在PHP 5.4版本，开发者Arnaud贡献了一个精巧的编译器层面的优化方案。 三元式 `条件 ? 真值 : 假值` 是一种简洁的条件表达式。在早期的Zend引擎实现中，编译器为它生成的操作码序列会引入不必要的临时变量和跳转指令，导致执行时存在微小的性能开销。Arnaud的优化方案直指核心：改进编译阶段的字节码生成策略。 通过分析抽象语法树，新方案能够更智能地处理三元式的求值路径。它避免了创建中间临时变量，而是让真值或假值的计算结果直接沿着更优化的指令流传递到最终存储位置。这个改动巧妙地利用了Zend虚拟机的执行特点，将原来可能需要的几次内存操作和跳转，简化成了一套更紧凑、更直接的指令序列。 虽然对于开发者而言，代码书写方式无需改变，但这次优化使得在条件分支密集或性能敏感的代码中，三元式的执行效率得到了可测量的提升。它展现了语言底层优化中那种“于无声处听惊雷”的魅力——通过编译器的智慧，让常见的语法结构跑得更快。
rebar和common_test使用实践和疑惑澄清
这篇讲的是作者在实际 Erlang 项目中，如何系统使用 rebar 和 common_test 这对组合，并坦诚地分享了自己从生疏到熟练过程中踩过的坑和最终厘清的认知。 作者从项目依赖管理、测试编译运行等日常开发环节入手，具体展示了 rebar 的常用命令和配置文件编写技巧。更关键的是，他深入 common_test 这一 Erlang 标准测试框架，结合 rebar 的集成环境，详细说明了测试用例的组织、初始化与清理（init/terminate）、以及如何调试那些看似随机的失败用例。文章特别澄清了几个常见的混淆点，比如 rebar 中 test profile 的实际作用范围，以及 common_test 的节点启动方式对测试结果的影响。这种基于实战的梳理，能帮助开发者避开配置陷阱，让测试流程更顺畅，从而更专注于业务逻辑本身的验证。
Erlang epmd的角色以及使用
这篇文章澄清了关于Erlang分布端口映射守护进程（epmd）的一个常见误解。很多开发者和运维人员会混淆epmd在Erlang集群中的角色，误以为它就是集群间通信的核心协议。 实际上，文章详细解释了epmd的本质：它是一个轻量级的网络目录服务，主要负责节点发现和端口映射。在集群启动时，每个Erlang节点会向epmd注册自己，并告知其监听的端口号。当其他节点想要连接时，会先询问epmd以获取目标节点的地址和端口信息，从而建立起直接的TCP连接。 文章进一步厘清了真正的通信机制。一旦节点间通过epmd获取了彼此的信息并成功建立连接，后续所有的分布式消息传递、RPC调用和Mnesia数据同步等，都将在这些已建立的直接连接上进行，epmd不再参与其中。理解这一分工至关重要，因为它解释了为什么在集群稳定后，即使临时关闭epmd服务，已连接的节点通信通常不会立即中断。 对于正在搭建或维护Erlang/OTP分布式系统的工程师来说，准确把握epmd的“目录服务”角色而非“通信中枢”定位，有助于更清晰地排查网络连接问题，并对集群的架构和容错设计有更深入的理解。
编程珠玑番外篇-K. Plan 9 的故事（修订版）
这篇修订版的番外篇重新讲述了Plan 9操作系统的故事，并得到了博文视点编辑的专业协助。作者从上世纪80年代贝尔实验室的创新环境切入，梳理了Plan 9作为Unix“精神续作”的诞生背景——其核心设计目标是彻底解决分布式计算中资源统一访问的问题。 文章特别聚焦了Plan 9极具前瞻性却又颇为“怪异”的技术思想：它将所有系统资源（包括网络）都抽象为文件，通过一套简洁的协议实现跨节点透明操作。这种极致的统一性在当时的硬件和网络条件下显得过于超前，却深刻影响了后来Linux等系统的设计。 修订版不仅厘清了早期版本中的技术细节和轶事，更探讨了Plan 9为何未能取代Unix成为主流。它指出，Plan 9的困境源于其纯粹的理念与现实的商业生态、用户习惯之间的鸿沟，但它作为一次大胆的“操作系统实验”，为分布式系统留下了宝贵的设计遗产。
用YAML构建数据测试DAO层
这篇讲的是如何给枯燥低效的DAO层测试“减负”。作者从开发者日常的痛点出发：测试DAO层时，总得手动拼装数据、调用方法、再肉眼核对数据库状态，这套流程繁琐又容易出错。 文章提出了一种更优雅的思路：将测试数据用YAML格式集中管理。通过预先定义好符合结构的测试数据配置，测试时程序可以自动加载这些数据并执行验证，从而用配置化、可复现的方式替代重复的人工操作。 核心方案在于将测试数据与测试逻辑解耦。YAML文件清晰描述了测试场景下的数据状态，让测试用例本身更聚焦于行为的验证。这种方法不仅能显著提升测试编写与执行的效率，也使得测试数据更易于维护和复用，确实能达到事半功倍的效果。
Varnish VS Nginx测试报告
这篇技术博客直接深入了 Varnish 和 Nginx 在性能测试中的正面对决。文章并非泛泛而谈，而是从具体的配置环境出发，对两者在高并发下的响应速度、吞吐量以及资源消耗进行了细致测量。 测试结果清晰地揭示了二者的核心差异：Varnish 在处理纯静态缓存时，因其高效的内存管理和 HTTP 协议优化，表现出了惊人的冷启动效率和极高的缓存命中率；而 Nginx 则凭借其更为平衡的资源占用（尤其是更低的 CPU 消耗）和强大的动态内容处理能力，在复杂的应用场景下展现出更高的通用性与稳定性。 文章特别分析了在长时间压力测试下两者的内存表现，Varnish 的优势窗口与 Nginx 的平稳曲线形成了对比。结论并非简单地判定孰优孰劣，而是指出：对于需要极致缓存性能的 CDN 或静态资源分发场景，Varnish 是利器；而对于需要兼顾动态代理、负载均衡和静态缓存的 Web 服务器或反向代理角色，Nginx 往往是更务实的选择。这篇报告为不同技术选型提供了清晰、数据驱动的参考。