谈谈JSONAPI在PHP中的应用

现在服务端程序员的主要工作已经不再是套模版,而是编写基于 JSON 的 API 接口。可惜大家编写接口的风格往往迥异,这就给系统集成带来了很多不必要的沟通成本,如果你有类似的困扰,那么不妨关注一下 JSONAPI,它是一个基于 JSON 构建 API 的规范标准,一个简单的 API 接口大致如下所示: JSONAPI 简单说明一下:根节点中的 data 用来放置主对象的内容,其中 type 和 id 是必须要有的字段,用来表示主对象的类型和标识,其它简单的属性统统放置到 at

在同一个系统里使用多个版本的软件

如果你有几房姨太太的话,那么想让她们和平共处,多半是痴人说梦。对程序员而言,虽然他们不会有娶几个老婆的好运气,但是很可能会遇到在同一个系统里使用多个版本的软件的情况,一旦处理不好,同样会焦头烂额。 下面通过一个例子来说明如何解决多版本共存的问题:PHP 如果使用带有 PGO 功能的 gcc 编译的话,那么可以在不修改一行业务代码的情况下,获得 10% 左右的性能提升。不过这要求 gcc 的版本至少要 4.5,而我的 gcc 版本是 4.4,因为 gcc 是一个基础应用,所以

SYN丢包的几个例子

如果出现 SYN 丢包,那么将导致严重的性能问题,如果没有严重到完全连不上,那么在延迟时间上会表现出明显的时间特征,比如:1秒,3秒,7秒,15秒,31秒,具体可以参考:「SYN和RTO」,本文不说这个,就说说哪些情况会出现 SYN 丢包。 SYN Flood 攻击: 攻击者通过伪造大量不存在的 SYN 请求来消耗服务器资源,正常情况下,SYN 请求会被放到半连接队列中,一旦队列满了,后续的 SYN 请求将会被丢弃。 比较容易想到的方法一个是加快淘汰无效 SYN 请求,可以

史上最LOW的PHP连接池解决方案

大多数 PHP 程序员从来没有使用过连接池,主要原因是按照 PHP 本身的运行机制并不容易实现连接池,于是乎 PHP 程序员一方面不得不承受其它程序员的冷嘲热讽,另一方面还得面对频繁短链接导致的性能低下和 TIME_WAIT 等问题。 说到这,我猜一定会有 PHP 程序员跳出来说可以使用长连接啊,效果是一样一样的。比如以 PHP 中最流行的 Redis 模块 PhpRedis 为例,便有 pconnect 方法可用,通过它可以复用之前创建的连接,效果和使用连接池差不多。可惜

实战Guzzle抓取

虽然早就知道很多人用 Guzzle 爬数据,但是我却从来没有真正实践过,因为在我的潜意识里,抓取是 Python 的地盘。不过前段时间,当我抓汽车之家数据的时候,好心人跟我提起 Goutte 搭配 Guzzle 是最好的爬虫,让我一直记挂在心上,加上最近打算更新一下车型数据,于是我便重写了抓取汽车之家数据的脚本。 因为我是通过接口抓取,而不是网页,所以暂时用不上 Goutte,只用 Guzzle 就可以了,抓取过程中需要注意两点:首先需要注意的是通过并发节省时间,其次需要注

SYN和RTO

前两天,我在微博上推荐了一篇朝花夕拾的文章:The story of one latency spike,文章中介绍了 cloudflare 工程师如何一步一步 debug 网络延迟问题,细细读来受益良多,不过我并不打算详细介绍那篇文章的细枝末节, 本文只摘录一个点: When debugging network problems the delays of 1s, 30s are very characteristic. They may indicate packet l

如何快速判断配置文件的路径

最近使用 pip 的时候感觉速度太慢了,感觉有必要改成豆瓣的豆瓣的镜像,可我记不清 pip 的配置文件路径了,当然可以用搜索引擎查询一下,不过还有更快的方法:strace! shell> strace -eopen pip 2>&1 | grep pip.conf open(/etc/xdg/pip/pip.conf, O_RDONLY) = ... open(/etc/pip.conf, O_RDONLY) = ... open(/roo

通过实例入门Golang

如果想学会一门新语言,不仅要多读文档,还要多看别人写的代码,更要强迫自己用新语言多写代码。我在学习 Golang 之前,读过好几本相关的书籍,不过总感觉没真正学会,于是我决定动手用 Golang 写一个能用的工具试试,因为 Golang 最大的优势就是 goroutine 和 channel,所以我觉得实现一个简版的 ab(Web 压力测试工具)应该是一个不错的选择,用 Golang 磕磕绊绊总算实现了预想的功能,能够计算 Requests per second 和 Time

说说压力测试工具

系统写好了,能不能顺利上线?一般来说我们需要做一些压力测试来判断。比如系统预计每天一百万的接口访问量,并且访问时段主要集中在早八点到晚八点,那么平均下来 RPS 大约是 22 次左右,不过用户的访问量通常不会很平均,假设峰值流量是平均流量的 3 到 5 倍的话,那么我们可以推断出项目要想顺利上线,RPS 至少应该达到 66+ 次,110+ 次更好。由此可见上线前用压力测试工具测试 RPS 是一个很重要的环节。 既然压力测试工具如此重要,那么我们不妨挑几个来说说: 首先说说

谈谈推荐排序

本文说的排序并不是指「冒泡」之类的技术概念,而是一个业务相关的问题。 举例来说:某个网站,每天都能产生很多数据,需要一个推荐列表页面来展示数据。最初是完全按照时间倒序来排序的,但是这样就产生了一个问题:新鲜的数据不一定是有价值的数据!假设某个时段灌水的数据比较多,那么用户当时在列表页看到的就都是灌水的内容。既然如此,不妨换个思路:给每个数据投票,投票规则可以按业务逻辑自定义,比如:每次评论加一票,每次转发加两票等等。然后按照投票数来倒序是不是就可以了?可惜还有问题:有价值的