本站木有非理性广告和有害内容,请大度地将本站加入广告屏蔽白名单吧~~~ ::博客文章推荐::

写点朋友遭遇的一系列不靠谱事儿吧 ③

: 系统/OS 木魚 18857℃ 41评论
前方高能预警!坑来了……
提醒:本章图太多!!

文人相轻

在上一任技术员神奇地离职后,费劲了千辛万苦,朋友招来了一个新的技术员。
然后这天,朋友跟我说……

image038

嗯,大概如此。文人相轻吧,大多数程序员看别人的代码都是狗屎。以前我看很多人的代码也觉得是狗屎,是狗屎的原因是看不懂。当然以前的我看现在写的代码应该也是狗屎,就像我现在看以前写的代码也都是狗屎一样。
我翻很久以前自己写的代码的时候,心里想的最多的就是,“这以前是哪个傻逼写的狗屁代码。” 0054.gif 

当然了,这种心理活动一般不会说出来。
好嘛,说出来了……

苦逼的面试

自从上任技术员卸任后朋友就走上了漫漫招聘之路。
不是,应该说在他卸任之前就已经在招募人手了,因为他感觉人手不够用。
可惜……

image039

这年头外面的人鱼龙混杂,23333……
在这之后,朋友始终处于病急乱投医的状态。比如。

image040

还有……

image041

image042

朋友之所以惦记着Redis,是因为之前我跟他有提起过用Redis提高性能……
说到这里我发现他对我说的话还是满上心的,就是我打码打得手有点疼。

购物车?会话车

在这之后的两个多星期里,朋友陪着那个新来的技术员一起加班,好像是折腾购物车之类的东东,大概意思就是在买票的时候顺便能一起把购物车里的东西结算一下,然后有了购物车之后倘若他们会善于利用购物车减缓数据库提交,那当然是极好的。
他们在折腾这些东西,我懒得去管,也就一点没过问。至于他们把购物车内容全扔Session里了,我也没啥意见。

其实我觉得有这时间,应该进一步修改系统的,把那些该静态化的东西静态化,该加缓存的东西加一下缓存。

说到这里,不得不提到之前的技术员搞的订单提交。当时搞的订单提交是这样的,就是当来一个订单提交请求后,开启一个数据库事务,直接扣库存,如果扣除失败了,那就是卖光了。
在说到这里的时候,我还被那个技术员教育了一下。原话如是说,数据库中的库存字段设计为UNSIGNED INT,也就无法小于0了,因此当库存没有的时候,就会失败,不会超卖。
然后他颇为得意地说,技巧。

image043

后来我测试了一下,的确当数据等于0的时候执行语句会报错,也就没再去追究了,虽然总觉得抢购项目里几秒内提交几百个订单全都扔到数据库这边排队是对数据库的不尊重……

大概两周后,那边有消息了,大概就是功能基本完成准备上线了。时值正准备第四波高峰。

加速乐的坑:始终200

用加速乐的免费CDN服务了。就在高峰到来前的几天,朋友找到我,说准备卖了,让我给压测一下看看系统是不是有问题。
然后他问了我一个问题,说点击购票后在弹出层里,如果要返回的话,点取消是可以的,但是点浏览器的后退不行,会回退到登录页,为啥。
这是一个经典的动态操作问题其实。不过轮不到我回答他这个问题,就发现了更多的问题,多到后来我忘记了这个问题……

首先遇到的就是加速乐这个免费的CDN的问题。
问题的起因是我在刷新测试的时候,发现首页的背景图每次都要很久才能完整显示。而我看了一下开发人员工具的网络嗅探设置,确认没有禁用缓存。

image044

然后仔细看这张图。返回的状态码是200不是304,说明服务器完整返回了所有的数据。而请求头中包含了 If-Modified-Since以及If-None-Match,说明浏览器本地有缓存,并且正确提交了验证数据。
关键点来了。
服务器的返回中,Last-Modified以及Etag与请求头信息完全匹配,这时候服务器应该返回304表明没有修改才对,但是!加速乐的服务器却返回了200,把整个文件全部重新传输了一遍。X-Cachehit表明这是CDN的响应,命中了CDN的缓存。
测试了很多遍后,赫然发现加速乐的CDN几乎不会返回304。只有当个别时候X-Cachemiss的时候,也就是CDN缓存未命中的情况下,才会返回304,这是源服务器返回的。
这样的话CDN的效率该有多低?怪不得我总觉得有加速乐这个CDN还不如没有快。

与此同时,这背景图高达几百K,确实有点大。于是我跟朋友反馈了两个意见,一个是图太大了,压缩下;再一个就是加速乐的响应总是200没有304,似乎有点问题,查查是不是加速乐的设置有问题,必要的话去咨询一下加速乐的客服。

image045

过了一会儿,朋友给我反馈回来加速乐的客服是这么回复的。

image046

加速乐前身是百度的,而百度所有的客服都是这个尿性,我深有体会,那就是他们都很忙,经常说话说着说着就没声儿了。
总之百度这些玩意儿都不靠谱,以后能不碰尽量不要碰。
看到这里的时候我突然想起来,我的网站也用了加速乐,难道也这样。
于是我先去百度的网站上看了下,确认不是自己知道的HTTP协议有问题。

image047

然后我就去自己的网站上看了下。

image048

尼玛。果然也是完全一样的情况。缓存标记都匹配的时候,CDN依然返回200,然后完整的内容。

最后我不甘心,直接改本地hosts解析,绕过了加速乐的CDN。

image049

……这说明什么?说明有CDN还不如没有。
于是我决定自己去找百度加速乐的工作人员问一下情况。

image050

image051

然后我就去找百度加速乐的客服了。之前因为他们的节点出问题导致访问故障的时候找过,所以还在我的好友列表里。
然后我惊奇地发现他们居然一模一样的回复。

image052 image053

就是这样,说着说着突然给我换了一个人。
然后……就再也没有回复了。

后来我也懒得去理了。
反正我在之前很多次事情中已经知道了百度的客服基本上都是这个尿性,说着说着人就不见了,问题也没解决,好像都很忙的样子……

后来我的措施就是,取消了主站在百度加速乐上的CDN加速。后面有时间衡量一下后看看是不是彻底取消他们的CDN。

不过话说回来,难道这是因为我自己不懂?反正结果就是这样了。
不过虽然我能给自己的网站取消CDN,朋友的却不能取消,因为他还需要靠CDN来隐藏网站IP防范攻击。所以除非换CDN供应商,否则问题好像无解了。
但是换CDN供应商存在着未知的风险和因素,而且马上要使用的系统,好像有点太过于仓促。总之,最终就搁下了这个问题,其实是被阿里云的问题掩盖过去了。

阿里云神坑再现:这次是解决不了的坑了,且伴攻击和漏洞而来

最终所有事儿都掉链子了。

首先就是阿里云出现了神坑。
而这件事儿,到现在为止,我都无力吐槽,而且阿里云方面也完全拿不出解决方案。

事情的发现,要把时间点挪到加速乐之后,在加速乐的问题无解后,我照例对系统用ab进行了简单的压力测试。但是,问题马上发现。

image054

这话我说错了,测完才知道,不是没多大变化,而是变化,相当大……
第二天,也就是上面说的卖票的日子到了。朋友找我帮忙做压测。
不过在测之前我还吐槽了一下加速乐,可见我完全没意识到真正的危机在后面。

image055

首先就是。

image056

image057

注意我的用词,低到令人发指。
具体怎么令人发指的?看大图。

image058

看到了吗?不到37次每秒,这性能比最开始的50来次都要低得多。
一开始的时候我被这个性能震惊了,怎么会低成这样,我知道你们改系统流程了,可是再大的改动再烂的水平也不至于把性能搞成这样吧,这特么还是两台机器负载均衡出来的结果,你们是在跟我开玩笑吗,就这性能还要去抢购?!
想到这里,我觉得要先冷静一下找原因,于是我先喝了一杯咖啡压压惊。

image059

我说的重传是指TCP数据,上次的ECN事件后,服务器上都还装着Wireshark。

后来我为了搞清楚是PHP的问题还是网络的问题,改用ab压测一个纯静态页面。

image060

你以为我会告诉你这是内网互联的测试数据吗??

然后我在对应的机器上本地测试了一下。

image061

说明问题完全不在网站本身。

Wireshark的监控出了很多类似下面的数据,我完全有理由相信这是网络层出了问题。

image062

image063

与此同时,我另外请教了技术群里的一些同学,他们也都给出了差不多的看法,觉得是内网的路由出了问题。

经过上次ECN一役,阿里云那边首先觉得就是ECN出了问题。

image064

但是很可惜,这次不是,因为从服务器的一开始就关闭了ECN。
就这样,与此同时,网站还在遭受着CC攻击,朋友为此只能选择启用加速乐的高级防护。

image065

就在这时,有人给朋友反馈了网站的漏洞,指出可以在未起售的时候手动猜测目标页面地址然后进入,可以实现提前购票。

image066

这个漏洞很显然是因为对应的页面没有对当前时间做任何校验。我看了一眼代码,确实如此。但眼下根本没功夫去鸟这事儿。然而那个新来的技术小伙子激情四射,偷偷去改了,这为晚上的崩溃埋下了一枚无比精准的地雷……这是我后来才知道的。

眼看着就到卖票的时间点了,阿里云的网络问题完全没有回音,漏洞加攻击,此刻加速乐的高级CC防护也来掺一脚,所有的静态资源绝大多数返回了521这样一个浪漫的错误。

image067

不得已关闭了加速乐的CC高级防护,过了一会儿,页面恢复了。

就在此时,新的问题又再次发现,那就是:一张票没卖出去。
虽然网站表现得很艰难,被各种问题蹂躏地死去活来,但还不至于一张票都没卖出去吧?那这每秒一千多的并发请求都在做什么?
很快地我赶紧用测试账号测试了一下流程,才发现问题:特么根本下不了单!
在下午阿里云和攻击以及漏洞种种事情之后,所有人都忘记了去测试整个流程是不是走得通。

怎么办?赶紧去查!
新来的小伙子被朋友骂去查代码。
与此,我用着自己极烂的PHP代码水平直接在线上查原因,终于……

image068

看到了吧,什么叫坑?就是本地改了没有测试直接丢线上,还特么的没有备份! 0015.gif 
想骂都找不到词了,少壮不努力,老大想骂人都没词儿。

此时过售票点儿已经快一个小时了,在这种情况下,我只能给出最靠谱的建议就是。

image069

而此时,心急的朋友已经另辟蹊径:直接把服务器回滚到前一天的节点了。

image070

与此同时,那个新来的技术员也找到错误的原因了。

image071

不过这错误真是让我好想骂人啊。

与此同时,虽然服务器被回滚了,但事情变得诡异了起来,那就是PHP页面执行速度开始变得异常缓慢。

image072

与此同时,还有更严重的问题,就是数据库结构被更新了,和现有的程序完全不匹配。

image073

一个问题没有解决,另一个问题出现,完全是无脑的节奏,根本没有时间去解决。
在此情况之下,朋友也只能无奈同意了推迟一两天再卖票。

这个新来的技术员被骂死了,然后给骂哭了,主动辞职不要工资了。这事儿我才知道丫居然是95后的小家伙。哎,比我小那么多……好忧桑。
但出于怜悯之心,我就劝朋友还是好好教育一下就好,毕竟态度不错,虽然经验欠缺。

有时间跟阿里云割据了

上次说到,给阿里云提交了工单。
而阿里云方面当天给出的回复是,高峰期网站监控到流量达到数十M,证明压力是可以打上去的,建议查查网站程序的问题。

image074

我之所以说40M都是静态资源,是因为静态资源用不到内网互联,应该不会有太大影响。
后来我熬夜不写代码去测试阿里云的服务器,为了朋友这么牺牲自己的时间我都被自己感动了。
感觉有点奇怪,新建了一个最简单的无内容的纯静态页,居然都性能奇低,本机测试却又是好的。

image075

具体测试结果是这样的。本机测试是这个结果。

image076

但是内网同样的压测参数,却是这样。

image077

阿里云给出的回复。

image078

好嘛,乃们工程师下班了,我还在苦逼地给你们测试。

后来我熬夜做了更加详细的测试,感觉阿里云这个网络真不是一般的奇怪。
参见下面三个结果。

新建一个目标服务器上的空网站,端口100,内容啥都没有,就只有一个静态页面。
然后在本机用ab测试,并发数从100到500,结果如下。

image079

可见基本上没有太大变化,维持在3400-3500RPS左右。

然后换另外两台服务器用ab通过内网IP去压测。

image080

从图中可以看出,趋势大致相同,在并发数225以及以下的时候,性能尚可(至少没惨不忍睹),但是在225以上,性能跌成了梯状。

第二个我通过朋友把这个结果反馈给了阿里云,大概他们也觉得问题有点麻烦,然后再加上朋友电话敦促他们必须解决因为隔天又要买票,于是他们用电话联系了我,最终加了旺旺来解决这个问题。

在解决问题的一开始,我就有点抓狂。因为他们在ab这个工具上拧巴了。
大概是朋友作为客户,给他们传递的信息不是很准确,因为朋友给他们说的是自己的网站业务速度非常慢,并且查了下不是应用自己的问题,要求他们解决。于是他们就无视了ab这个工具,觉得这个工具测出来的不是准确的数据,还是先来压测业务本身。
我跟他反复强调静态文件都那么烂了还测什么业务,然后他跟我杠上了。
最后我差点要骂人了,终于我说,你别管客户怎么跟你说的他啥都不懂,你以我说的为准,你只需要帮我解决静态文件的问题就行了,业务上的事儿我自己会解决。 0015.gif 
然后他问我是不是确定这样可以,我说没问题,他说那好吧。
于是互相加了旺旺来解决这个问题。

他一上来就用Linux使用公网IP按照我给的命令行压测目标机器。

image081

……668RPS。吓尿了。为啥公网会比内网还快?
我以为在这时间差中问题无声无息地解决了。
可是内网重复测了一下,我确定问题还是有。

image082

然后我就郁闷了。

image083

于是我的人生观要被改写了,难道是Server2012到Server2012有问题……

image084

想到这里,我决定改用Server2008做客户端试试,后来证明这个完全没有改善,依然是那个蛋德行。

这时他提出了一个方案,就是他找一个机器临时部署一个nginx,然后从这边访问过去压测。

image085

他本机测了一下,是这个结果,证明服务器没问题。

但是到我这边,用Server2012去访问后,就变成了这个蛋德行。

image086

36!36!36!蛋疼的事情要说三遍。
到这里,我的精神几乎处于崩溃边缘,难道选择Server2012是个错误……
于是我果断换了一台Server2008R2测试。
好吧依然是这个德行。

image087

这时候,他开始打ab的主意了……他觉得我用的ab有问题……因为他用Linux压过来可以,那就不是网络有问题…….

image088

然而我已经抓狂了……你说jmeter就jmeter吧,随便你折腾。
你说Linux下是5700还是7000纠结这个有意思吗。。

image089

我发誓我当时真想把鞋砸他脸上,如果能砸得到的话,因为为了配合他的测试,我都已经把其中一台服务器重置为全新的服务器了。

在这之后,大概他觉得确实有点问题,就自己在另外一个区搞了两台Server2012测试,好像也是一样的情况,然后就交给后端去查了,让等待……哦呵呵,能等出啥结果,后面会看到,不过几天内是不会看到有回应是妥妥的了。

image090

为了这事儿已经把服务器全部换了一拨了。
现在咋办?

简单,继续掉链子!

阿里云的问题暂时搁浅,但至少不是完全不能用。第二天朋友又飞另外一边,下午委托我监控一下服务器,晚上卖票。
虽然网站网络有问题,但好在前一天测试过整体流程,应该没啥问题。
然而,我想多了。

这一天新来的小伙子就修漏洞,我没管他,我也有自己的工作好吗,为这事儿我已经耽搁很多工作了。
然后晚上快买票了,我召唤了那个小伙子,说快买票了,你去系统测试下线上的有没有问题。
他说好。

image091

然后他就没给我回音了。
我以为没事儿,就没管他们了。

结果朋友在快八点的时候从客户那边给我电话说,怎么回事没有一点数据,还要给客户演示的这下麻烦了。我心想不是正常吗啥没有数据。
于是我赶紧去现场测了一下,卧槽没法下单,下单的时候500错误!

image092

跟他对话完我已经没心思骂他了,尼玛我让你现在测你拿着昨天的东西说可以到底是几个意思。 0015.gif 
我觉得此刻也根本没法依赖他了,依赖他的靠谱程度还不如我的三脚猫PHP功夫。
后来证明确实没法依赖他,因为问他啥事儿都没回应,最后干脆跟我说,啥都不知道。

image093

还有比这更离谱的事儿吗?想骂人都骂不出来。
后来我直接撇开了他,还求助了同事关于ThinkPHP的细节,终于在四十分钟后找到了错误日志,错误日志显示数据约束错误,然后继续往前面捋代码,发现是登录的时候写到Session里的数据缺少了一个必须字段,导致数据库报错了。
而登录代码之所以会变动,是因为只对密码MD5没加盐,这个新来的技术小伙子觉得不安全,自己改了加盐的代码。

且不说加盐是不是应该在这种时候改,改完了都不测试一下流程吗?! 0015.gif 
我完全不知道怎么吐槽了。
而就在半个小时前,已经通过前端跳转,将所有业务重定向到淘宝上去了。

九点半的时候我从公司走,朋友来电话说,他被踢了,因为那个技术员干脆把手机关机,彻底不接他电话了……

再后来就是,因为这连续两次彻底的掉链子,不仅新的业务没拿下来,之前的既有业务基本上也都黄了。

于是……后来这位朋友就联系不到了。 0166.gif 

image094

这充分说明了自己手下人靠谱程度其实直接决定了你的业务能不能活下去。

争取最后机会

朋友觉得还有机会可以争取,所以问我怎么办比较好。
于是我决定给他搭一套新的东西。既然Server2012到Server2012有问题,那简单,负载均衡换成CentOS不就好了。
于是从来没有部署过线上CentOS服务器的我,竟然能摆平MySQL+Tengine+PHP,所有的业务都能跑通,连自己都开始佩服自己了,连编译安装都搞定了。
当然PHP是跑在CentOS7本机的,没有跑在Windows上,虽然依然有一台Windows Server 2012。

等等,之前的性能问题没有下文了?
NONONO。

依然是那狗屁的性能

虽然现在没有反代的需要了,但我依然用ab从各个平台之间互相压测了一下看看是不是有问题。
然后!我就发现有问题了。
而且这个问题很奇怪的,Server2012压CentOS没问题,两台机器本机压测没问题,但是Server2012压测CentOS依然出了问题,而且是大问题。

为了清晰地表述问题,我将用数据来说话。 0042.gif 

首先说一下测试环境。

  • 服务器A:CentOS7,Tengine最新版
  • 服务器B:Windows Server 2012,IIS8
  • 用来测试的文档分为三个,分别为1KB,2KB,4KB。

首先我们在CentOS上本机压测,分别测试1K、2K、4K的文档,在并发500下的性能。

image095

image096

image097

从上面的结果可见,CentOS本机压测的时候,吞吐率基本上维持在9000+RPS,比较正常的表现。

然后我们再看下CentOS压Server2012的表现。

image098

image099

image100

可见,虽然不是本机是通过网络的,但性能还是挺高的,在文件不大的情况下,比Tengine本机测试都高。

好像没有问题,从服务器到网络都没有问题对吗?
错!图样图森破!桑塔么司乃衣服!! 0015.gif 

看看Server2012压测CentOS的结果!!

image101

image102

image103

是不是看到了相似的一幕?是的,这里都是500并发,但是文件越大速度越慢,2K的时候已经跌破了100RPS,而到4K的时候,已经彻底完成不了了——反复测试了很多次,每次都会在最后几个的时候挂掉。

看到这里,我气不打一处来。 0015.gif 
让朋友去阿里提交工单。

然后他们的反馈是!!!

image104

……好嘛,这回赖ab工具了,好吧,工具有问题。
我现在才发现,之前的那个旺旺上的工作人员,也是这么回复我的。

image105

呵呵,ab有问题。
呵呵,打脸什么的我最喜欢了。 0078.gif 

反正我能找到另外的服务器来测试。
找不到就偷。

image106

哪怕并发加到1000也并不会导致性能有怎么降低。

image107

要知道,这测试的内网还是100M带宽而已,并不是千兆的。

image110

作为被我打脸的回应。

image108

……建议用PTS来测。PTS是啥呢……

image109

哦。呵呵…… 0015.gif 

结束

写得我累死了,八十多页的Word文档。

总的来说就是,这事儿黄了,Over。

最后项目没有能继续,朋友也心灰意冷,仅此而已。

 

好了,系列写完,本章花了我三个多小时,因为槽点实在太多……已经是三点四十了……
喜欢 (56)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
(41)个小伙伴在吐槽
  1. 我也是,基本看不懂还是看完了,该佩服鱼鱼还是自己呢

    阴世幽泉2020-08-11 00:37 回复
  2. 我居然看完了,虽然什么都看不懂。

    不愿透露姓名的王二狗先生2019-12-31 14:04 回复
  3. 阿西吧。。。竟然看完了。。。

    极度2019-08-22 17:03 回复
  4. 木鱼你真牛,花那么时间来分享这个!点赞,哈哈。

    NULL2019-01-17 14:47 回复
  5. 随然看不懂写的什么,但是感觉很厉害的样子。

    李先森°2018-11-28 15:53 回复
  6. 我也是服了,每次我搞完新版本,巴不得每种情况都测试一遍,需求的时候碰到不合理我也会直接提出来。居然会有这么不靠谱的人,也是服了

    q7406101022018-04-02 17:16 回复
  7. 看的惊心动魄的,我也希望有鱼大这么一个朋友。你朋友真幸福!icon_smile.gif

    Gang2018-02-12 16:06 回复
  8. 这小说看的我惊心动魄,感觉上线的是自己的项目

    青木2017-07-07 14:21 回复
  9. 看完,觉得,你朋友应该庆幸有你这么个朋友。哈哈

    前路漫漫,勇往直前2016-09-21 17:57 回复
  10. 鱼大你这朋友怎么遇到这么多坑,被自己的人坑,被阿里云坑,简直了。。。。好心塞,哈哈哈哈哈哈

    咔咔NG2016-09-17 12:56 回复
    • 心塞完了还哈哈哈你觉得合适吗。。

      木魚2016-09-18 15:04 回复
  11. 完全看不懂你说的那些数据,居然看完了三篇,而且觉得很有意思,哈哈哈哈哈哈哈哈,隔一段时间来你网站找点乐子。

    浮云过影2016-04-28 13:56 回复
  12. 阿西吧。。。竟然看完了。。。72.gif

    Reghzar2016-03-12 21:55 回复
  13. 所以阿里云的问题到最后也没有解决啊……(汗)

    BROBIRD2016-02-17 22:36 回复
  14. 看起来很神奇的样子

    bbis2015-12-21 00:26 回复
  15. 木鱼大大,你需要女盆友么?现在超级崇拜你

    墨墨2015-12-18 18:07 回复
  16. 我三篇都看完了,鱼大好厉害,跪着膜拜!

    大霈2015-12-11 10:52 回复
  17. 第一次来看博客,,,一口气看了三篇。。额,,最后一篇实在太长了,,看了3分之一,,后面省略。。。让我膜拜一会。。。。

    脆橘子2015-12-08 15:20 回复
  18. 给力!收获颇大!感谢鱼兄分享

    夜游神2015-12-05 10:02 回复
  19. 第一次来你博客竟然看完了3篇,好几个小时过去了。。。
    你朋友挺背的,请到这样一批人。

    最后感觉可惜了,你朋友现在估计已经心灰意冷了。

    MeeSii2015-11-13 00:10 回复
  20. 关于缓存
    1:本地缓存 就是浏览器缓存, 这个是返回304
    2:前端的静态缓存 是CDN加速服务器对文件的缓存 这个返回肯定是200

    鱼兄 有误解的是把 本地缓存和前端静态缓存混淆了, 我看了返回200的截图 返回的http头说明 CDN缓存命中了,只是配置MAG-AGE 这样通知浏览器进行缓存的标识设置的比较短,浏览器没有缓存成功 所有到CDN的服务器去内容了,而这个文件并没有回原到服务器, 鱼兄放心使用 ,这个是被缓存了,(CDN的前端缓存)

    star2015-09-29 13:53 回复
    • 我想我并没有误解什么……首先,浏览器肯定是缓存成功的,但是按F5刷新的时候浏览器为了尽可能更新资源所以依然发了请求,并且带上了当前缓存文件的信息(更新时间和ETag),这个从抓包结果很明显体现了。在正确的情况下,服务器应该以304响应这些请求(因为文件并没有更改,所以服务器应该以此响应确认客户端文件是最新的),而不是以200+所有内容来响应客户端请求。这里的关键不是是不是回源,而是CDN服务器是不是应该做无用的传输,这点从后面绕过CDN后服务器正确的304响应可以看出来。另外,CDN响应的过期时间是一个月后,所以也不是标识设置比较短的关系,之所以会引发这个请求即便是有缓存且没过期,那是因为按F5导致的刷新而不是自然导航。

      木魚2015-09-30 18:07 回复
  21. 看的好蛋疼。 你请一个月假,帮他优化了。

    人家肯定也不会亏待你。

    妥妥的,这多蛋碎

    那个同学2015-09-25 13:13 回复
  22. PHP才是最好的语言!

    小dnp2015-09-24 18:52 回复
  23. 0001.gif 很好,很好的经验。骂人找词,请找我。

    oook2015-09-24 15:10 回复
  24. 非常好的文章,辛苦了!

    jyy2015-09-24 14:33 回复
  25. 点了赞但没有刷新数字

    fifteen2015-09-24 11:56 回复
    • 嗯,自定义主题的点赞是自定义字段,WordPress没有在这个时候刷新缓存。

      木魚2015-09-24 13:27 回复
  26. 连看三篇,比看小说还过瘾,一上午都过去了,都特么赖木鱼!

    Q2015-09-24 11:04 回复
  27. 是不是阿里的服务都很坑爹啊!前段时间好像说阿里云删除用户配置啥的,这个是真的这么坑爹么?还有鱼大的建议是不是下次建站都用Linux?

    iphyer2015-09-24 10:34 回复
    • 那倒不是,不需要把阿里云的问题归结给操作系统。

      木魚2015-09-24 13:24 回复
  28. 感觉还是你朋友找的人不靠谱 创业公司能走多远 不仅看员工的工作能力 还得看员工的个人素质

    abc2015-09-24 10:13 回复
    • 同感觉,这么不靠谱也能找到工作?

      iphyer2015-09-24 10:36 回复
  29. 曹点略多,主要是新来的小伙不负责!不然也不会这么严重!

    汪灵酱2015-09-24 10:12 回复
  30. 看到这句“……建议用PTS来测。PTS是啥呢……”正高潮迭起…..然后Over了?
    不要酱紫58.gif

    xiaotiannet2015-09-24 09:52 回复
  31. 巴拉巴拉 不明觉厉。。。

    啦啦啦啦啦啦2015-09-24 09:45 回复
  32. 不是技术猿。居然看完了。我还喜欢段子,各种撕逼的段子。让我有看故事会的赶脚。。哈哈6.gif

    barely2015-09-24 09:30 回复
  33. 感觉Server 2012才是坑啊。

    bayeux2015-09-24 09:01 回复
    • 2008和2012R2在我看来其实没啥问题,性能足够管理方便也够稳定,问题是在阿里云方面

      木魚2015-09-24 13:22 回复
  34. 阿里的服务这么差?他上面其他的网站怎么玩的啊

    汝泉2015-09-24 08:28 回复