帖子

目前显示的是 四月, 2015的博文

Markdown的选择

我一直在思索用什么格式存储文档比较好。之前一直在用google docs,但是它的格式不公开,上传/下载的时候需要转换格式,转换的时候必然会丢失一些信息。于是后来想,那还是纯本文或者markdown吧。选型但是Markdown方言很多,选哪个好?我考察了以下三个。pandoc. John MacFarlane写的,万能的转换器。对我来说一个缺点是它的是Haskell语言。commonmark. 这是John MacFarlane搞的对markdown进行标准化的一场伟大尝试。他给出了C语言和js的实现,其中C语言的很容易在windows下编译过去,代码简单易懂。可惜,没人买账。GitHub Flavored Markdown. 这个大概是现在事实性的标准了。因为代码都托管在github上,所以写文档的时候自然也就顺着 github 的要求来。我没有找到它的开源实现。但是,atom.io是github公司的,而这个编辑器的markdown实现用的是marked. 我试了下还不错。Ghost markdown. 这是我现在所用的blog engine Ghost的markdown方言。它内部用的是showdownjs 这个库,然后自己写了一些扩展。语法高亮它是自己做了一些简单的字符串替换,生成Html5的code标签格式。但是html5的<code>标签目前没有浏览器去做高亮,所以还是得借助于在前端嵌入highlight.js这样的东西。markedmarked 用起来比较简单,可以传自己的highlight函数进去。比较容易和highlight.js配合。我用的时候比较头疼的是marked的换行功能非常有问题,请参见github上的issue 115. 2年多了,一直没人修。数学公式html header中再加上一行mathjax的js链接,就可以在markdown中支持数学公式了。 不过由于‘\’在markdown中是转义字符,所以写‘\’的时候要连写两个。Othershighlight.js既可以用在服务器端,也可以用在浏览器里。但是我更倾向于在服务器上使用,让client端更瘦一点。

我在Yahoo与ATS 九死一生的故事

图片
去年9月,我去Yahoo后领导交给我的第一件事,就是把Yahoo内部一个过时的、已经End-Of-Life的http server换成Apache Traffic Server(ATS)。这件事情就类似于把某网站的架构从apache+tomcat变成nginx+tomcat一样,可以说非常简单。我只管更改一下安装脚本,剩下的让运维工程师去线上操作就行了。Too easy!! 然而没想到遇坑无数,我悲惨的人生就此开始。详情见下文。100-continue导致响应慢请见这个jira https://issues.apache.org/jira/browse/TS-1125 的Description。调用我们服务的client service是使用C++基于libcurl实现的。而curl默认开启了一个很废柴的功能,就是当post body大于1k的时候,它会在Headers中加上"Expect: 100-Continue"。 当它收到100 continue的response header之后,它才会继续把body post过去。而ATS以及我们后端的App Server默认根本不理解这个东西,于是就导致curl一直卡在那里,等到timeout,然后才post body。解决方法: Yahoo的Feifei Cai在2014年4月提交了一个补丁,使得ATS能够识别"Expect: 100-Continue"。该补丁已经被merge进去了。我只需要在配置文件中打开proxy.config.http.send_100_continue_response,那么ATS就会自动回复100 continue。问题"似乎"解决了。其实如果我们能说服调用方修改下他们的代码,禁用掉curl的这个功能,那么不仅能降低相应延迟(因为能减少一个RTT),而且也没有100 continue的麻烦了。可惜,不能。本地端口耗尽很遗憾的是,ATS与我们的backend(即origin server)之间并不是长连接,每来一个请求就需要建立一个TCP连接,每建立一个TCP连接就需要占用一个端口,于是很快就遇上了本地端口耗尽的问题。 Linux默认的time wait是180秒,也就是说5万个端口只够应对每秒270个HTTP请求。这是一个非常常…

Bye, Yahoo

图片
Yahoo北京研发中心正式关闭了。3月31日是最后一天。所有不relocation到美国的同事,都在30日和31日办完了离职手续。 于是乎,我也要正式开始找工作了。