最新 | 最热门 | 最高评价

+0  一个HTTP小问题

Tag: Technical | HTTP
老王 发于 2014年02月25日 18:59 | 点击: 1262 | 展开摘要
同事叫我帮忙解释一个问题:一个PHP生成的重定向请求,在Nginx日志里产生两种截然不同的记录:一种响应体大小是零个字节;另一种响应体大小是五个字节。

现在年纪大了,面对问题时的嗅觉不再灵敏,第一感觉零是正确的,心想是不是重定向后忘记退出了,后面还有内容输出,可是查了一下代码发现没有问题:

<?php

header('Location: /path');
exit;

?>

绕了一圈后,我猛然意识到Nginx缺省开启了分块传输,没有「Content-Len

查看全文: http://www.udpwork.com/item/11768.html

+0  如何安全的Include文件

Tag: Technical | PHP
老王 发于 2014年02月25日 11:50 | 点击: 1027 | 展开摘要
似乎多数人都觉得Include文件是一件非常简单的事情,可惜漏洞往往出现在我们忽视的地方。正所谓千里之堤溃于蚁穴,二战期间,法国人寄希望与马奇诺防线,却忽视了原本认为非常安全的阿登高地,让德国人有机可乘,最终的结果大家都知道了。

下面这个例子虽然是我杜撰的,但是我确信现实情况里一定存在类似的问题:

<?php

$debug = false;

// ...

$config = include 'config.php';

// ...

if ($debug)

查看全文: http://www.udpwork.com/item/11765.html

+0  通过FastCGI Cache实现服务降级

Tag: Technical | Lua | Nginx
老王 发于 2014年01月13日 11:29 | 点击: 1334 | 展开摘要
在自然界中,很多生物面临生死考验的时候,往往会做出惊人的反应,其中最为大家熟知的当属壁虎,危难关头,与其坐以待毙,不如断尾求生,通过自残来换取活下去的希望。对于互联网项目而言,同样存在着很多生死考验,比如:访问量激增;数据库宕机等等,此时如果没有合理的降级方案,那么结局必然是死路一条。

任何问题一旦脱离了实际情况,便失去了讨论的意义。在继续之前,不妨先介绍一下案例的背景情况:一个PHP网站,以读为主,原本躲在CDN后面,运行很稳定,后来新增了很多强调个性化的需求,便去掉了C

查看全文: http://www.udpwork.com/item/11523.html

+0  再叙TIME_WAIT

Tag: Technical | Linux | TCP
老王 发于 2013年12月31日 20:17 | 点击: 1288 | 展开摘要
之所以起这样一个题目是因为很久以前我曾经写过一篇介绍TIME_WAIT的文章,不过当时基本属于浅尝辄止,并没深入说明问题的来龙去脉,碰巧这段时间反复被别人问到相关的问题,让我觉得有必要全面总结一下,以备不时之需。

讨论前大家可以拿手头的服务器摸摸底,记住「ss」比「netstat」快:

shell> ss -ant | awk '
NR>1 {++s[$1]} END {for(k in s) print k,s[k]}
'

如果你只是想单独查询一下

查看全文: http://www.udpwork.com/item/11447.html

+0  浅谈TCP优化

Tag: Technical | Linux | TCP
老王 发于 2013年11月21日 11:33 | 点击: 1822 | 展开摘要
很多人常常对TCP优化有一种雾里看花的感觉,实际上只要理解了TCP的运行方式就能掀开它的神秘面纱。Ilya Grigorik 在「High Performance Browser Networking」中做了很多细致的描述,让人读起来醍醐灌顶,我大概总结了一下,以期更加通俗易懂。

流量控制

传输数据的时候,如果发送方传输的数据量超过了接收方的处理能力,那么接收方会出现丢包。为了避免出现此类问题,流量控制要求数据传输双方在每次交互时声明各自的接收窗口「rwnd」大小,用来表

查看全文: http://www.udpwork.com/item/11173.html

+0  记录一个软中断问题

Tag: Technical | Linux
老王 发于 2013年10月30日 16:17 | 点击: 1273 | 展开摘要
前些天发现XEN虚拟机上的Nginx服务器存在一个问题:软中断过高,而且大部分都集中在同一个CPU,一旦系统繁忙,此CPU就会成为木桶的短板。

在问题服务器上运行「top」命令可以很明显看到「si」存在异样,大部分软中断都集中在 1 号CPU上,其它的CPU完全使不上劲儿:

shell> top
Cpu0: 11.3%us, 4.7%sy, 0.0%ni, 82.5%id, ... 0.8%si, 0.8%st
Cpu1: 21.3%us, 7.4%sy

查看全文: http://www.udpwork.com/item/11039.html

+0  如何正确配置Nginx+PHP

Tag: Technical | Nginx | PHP
老王 发于 2013年10月23日 20:11 | 点击: 1409 | 展开摘要
对很多人而言,配置Nginx+PHP无外乎就是搜索一篇教程,然后拷贝粘贴。听上去似乎也没什么问题,可惜实际上网络上很多资料本身年久失修,漏洞百出,如果大家不求甚解,一味的拷贝粘贴,早晚有一天会为此付出代价。

假设我们用PHP实现了一个前端控制器,或者直白点说就是统一入口:把PHP请求都发送到同一个文件上,然后在此文件里通过解析「REQUEST_URI」实现路由。

此时很多教程会教大家这样配置Nginx+PHP:

server {
listen 80;
s

查看全文: http://www.udpwork.com/item/11012.html

+0  通过Strace定位故障原因

Tag: Technical | Strace
老王 发于 2013年10月06日 01:07 | 点击: 1981 | 展开摘要
俗话说:不怕贼偷,就怕贼惦记着。在面对故障的时候,我也有类似的感觉:不怕出故障,就怕你不知道故障的原因,故障却隔三差五的找上门来。

十一长假还没结束,服务器却频现高负载,Nginx出现错误日志:

connect() failed (110: Connection timed out) while connecting to upstream

connect() failed (111: Connection refused) while connecting to up

查看全文: http://www.udpwork.com/item/10866.html

+0  Nginx与Gzip请求

Tag: Technical | Lua | Nginx
老王 发于 2013年09月02日 23:20 | 点击: 1194 | 展开摘要
前些天,移动端的同事跑来问:某些API需要传输大数据,Nginx服务器能否支持Gzip请求?一方面可以节省移动端流量;另一方面还可以加快传输速度,提升用户体验。对于Apache来说,利用SetInputFilter,可以很轻松的实现这个功能,那么Nginx如何做呢?

既然移动端发送的是Gzip请求,自然需要想想如何在服务端解压缩。搜索一下现成的Nginx的模块,发现和Gzip相关的模块有如下几个:

Gzip: Gzip responses.

Gzip Precompre

查看全文: http://www.udpwork.com/item/10580.html

+0  闲扯Nginx的accept_mutex配置

Tag: Technical | Nginx
老王 发于 2013年08月24日 23:35 | 点击: 1084 | 展开摘要
通常多数人不会注意Nginx的accept_mutex配置,不过实际上它对系统的吞吐量有一定的影响,今天生物钟紊乱睡不着觉,索性闲扯一下Nginx的accept_mutex配置。

让我们看看accept_mutex的意义:当一个新连接到达时,如果激活了accept_mutex,那么多个Worker将以串行方式来处理,其中有一个Worker会被唤醒,其他的Worker继续保持休眠状态;如果没有激活accept_mutex,那么所有的Worker都会被唤醒,不过只有一个Work

查看全文: http://www.udpwork.com/item/10489.html

+0  初窥InnoDB的Memcached插件

Tag: Technical | Memcached | MySQL
老王 发于 2013年08月20日 17:32 | 点击: 1299 | 展开摘要
前些年,HandlerSocket的横空出世让人们眼前一亮,当时我还写了一篇文章介绍了其用法梗概,时至今日,由于种种原因,HandlerSocket并没有真正流行起来,不过庆幸的是MySQL官方受其启发,研发了基于InnoDB的Memcached插件,总算是在MySQL中延续了NoSQL的香火,以前单独架设Memcached服务器不仅浪费了内存,而且还必须自己维护数据的不一致问题,有了Memcached插件,这些问题都不存在了,而且借助MySQL本身的复制功能,我们可以说是变

查看全文: http://www.udpwork.com/item/10432.html

+0  笨法算RPS

Tag: Technical | AWK | Gnuplot
老王 发于 2013年07月25日 23:22 | 点击: 1124 | 展开摘要
计算RPS最简单的方法是用一天的总访问量除以一天的总秒数,不过这样得出的结论只是一个平均值,无法反映各个时间点的真实情况,真正有价值的是即时的RPS数据,如果有一个比较好的监控系统的话,这并不难,可惜我没有,而且实际上我遇到的问题还要更复杂些:大部分接口是PHP写的,少部分接口是LUA写的,为了更有针对性,需要分别计算PHP和LUA的即时RPS数据。

这里让我们假设Web日志已经做了按天分割,如果你不清楚怎么搞,可以参考我前一段时间写的:「被遗忘的Logrotate」,日志

查看全文: http://www.udpwork.com/item/10291.html
|<<<45678910>>>| 一共12页, 139条记录