手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:thinkinlamp

thinkingo收获

我不知道别人是否和我一样喜欢记录点东西,但是我知道我必须要记,因为年纪大了,如果不记录下来,很可能什么都忘了。

(伤心,我大约写了将近3000字的内容。没了,说实话,让我再写,可能写的没有刚才全了,希望我还能写点什么吧)

这次thinkingo的聚会对我来说真的是记忆犹新了。不谈路上堵车2小时吧,在高架上完全不能动,导航里写的只要半小时的路径走了2个小时。且谈好不容易写的心得吧。因为蓝牙鼠标左键失灵导致我以为是程序死了。让我重启了两次电脑 ,而明明sablog上面写的自动保存成功,却其实只保存了上文括号上面的那一句话。果然是老了。电脑也不帮我了

OK,让我再来一次吧,今天三个议题和一个话题

1、astaxie 的 go在cdn项目中的应用。

开始看到这个话题的时候,我还在想,今天是不是会话题重复了,毕竟七牛也是做云存储和CDN的,但后来发现asta讲的内容其实是内容分发这一块的,他们用go重新实现了内容分发模块,而原来则是用BT协议实现的。基于BT协议,有两个小问题:1.有1%的情况下,服务器节点只能从中心服务器取到99%的数据就卡死了。2.BT的搜索是无序的,不会优先从本地局域网进行下载,而是随机从任意节点下载,带来的问题就是机房的带宽反而被BT协议占用了不少,浪费了不少的流量费(现在的修改过的各种类BT协议,都调整过了,比如迅雷就宣称,会优先在局域网中下载从而避免流量占用过多)

asta他们则用go写了个分发协议,即中心服务器向节点发起通知,他们会先根据节点的机器数来进行数据块下载的分配 ,比如一个20个数据块,分散到节点的4台机器上则可能是1~5在第一台,6~10在第二台下载,以此类推,每个节点的机器下载完毕后通知中心服务器。这样中心服务器就知道哪些机器下载了哪些数据块。然后再通知第一台服务器从第二台上下载6~10,从第三台上下载11~15,以此类推。也就是说该节点的互联网流量其实就只消耗了整体数据的一次下载流量。而以前四台服务器,就下载完整的包四次,现在只有一次,其他的都是内网流量了。

这让他们不但节约了流量,还加快了速度

2、邵天宇 介绍了工作中对go的应用

邵天宇 他们公司是做微博方面的应用,这玩意大家都懂,其实能够从微博里挖掘数据都往往都是那些4A公司,现在也有越来越多的工司也开始慢慢在做这方面的工作,只有做的越多,才能越了解数据。gopher介绍他用go实现以前用python的功能后,CPU和内存的占用率都明显下降,性能更高。

邵天宇 介绍了几个他们公司用的一些用户分群的算法,细化到后面就是图的应用。

邵天宇 还介绍了他们使用的全文索引,说有个国内版的,整合了:Elasticsearch + IK,然后再加上leveldb来做处理,性能还算不错,原来是用wukong + sego,可是wukong的索引是存在内存里的,一旦机器重启就啥也没了。最后不得已才改用Elasticsearch + IK 。。(下次我也可以尝试一下)

3、七牛的韩拓介绍了下七牛中的GO使用情况 

用韩拓的话来说,go的程序占据了他们的核心代码 的99%左右,但并不代表他们只用go来做所有的事,这可是一件蠢事,所以他们还是用了很多解决方案,比如lvs+nginx来解决高可用性的问题。用memcached来解决数据缓冲的问题等等

当然他介绍的最多的是他们日志系统,除了程序日志外,还有他们的事务日志。程序日志是他们的底层,事务日志是在程序日志的再一层包装。他们用日志系统包围了他们几乎所有的程序。即在程序的处理外层是被日志系统包围住的,日志系统就是一个蛋壳。它几乎充当了其他语言的try/catch,避免程序崩溃(这是我的理解,希望没有理解错)。虽然性能上有一点损失,但得到了更完整的日志,既可以分析系统,也能够用来当作收费依据。因此这些性能损失完全能够接受

----

话题中,韩拓提起了GC,引得大家一番热列的讨论。认为GC实在不可控。为了避免GC消耗大量的时间,每个人都有一些自己的看法,其实这个话题之前在知乎上已经有人讨论过:

http://www.zhihu.com/question/21615032
  1. 先介绍下我的情况,我们团队的项目《仙侠道》在7月15号第一次接受玩家测试,这个项目的服务端完全用Go语言开发的,游戏数据都放在内存中由go 管理。    
  2.     
  3. 在上线测试后我对程序做了很多调优工作,最初是稳定性优先,所以先解决的是内存泄漏问题,主要靠memprof来定位问题,接着是进一步提高性能,主要靠cpuprof和自己做的一些统计信息来定位问题。    
  4.     
  5. 调优性能的过程中我从cpuprof的结果发现发现gc的scanblock调用占用的cpu竟然有40%多,于是我开始搞各种对象重用和尽量避免不必要的对象创建,效果显著,CPU占用降到了10%多。    
  6.     
  7. 但我还是挺不甘心的,想继续优化看看。网上找资料时看到GOGCTRACE这个环境变量可以开启gc调试信息的打印,于是我就在内网测试服开启了,每当go执行gc时就会打印一行信息,内容是gc执行时间和回收前后的对象数量变化。    
  8.     
  9. 我惊奇的发现一次gc要20多毫秒,我们服务器请求处理时间平均才33微秒,差了一个量级别呢。    
  10.     
  11. 于是我开始关心起gc执行时间这个数值,它到底是一个恒定值呢?还是更数据多少有关呢?    
  12.     
  13. 我带着疑问在外网玩家测试的服务器也开启了gc追踪,结果更让我冒冷汗了,gc执行时间竟然达到300多毫秒。go的gc是固定每两分钟执行一次,每次执行都是暂停整个程序的,300多毫秒应该足以导致可感受到的响应延迟。  

300多毫秒,韩拓说他们遇到过是5秒左右,在线上运行的时候,gc停止了5秒左右。5秒对于我们来说没有什么,但对于一个做高可用的企业来说,已经是有点夸张了。

----
实在不想写了,很痛苦。之前写的全没了,就记录这么一点吧。(这次写的时候,居然又超时了,所幸我ctrl+s,保存了下来。天啊。。。我快崩溃了)

Tags: thinkinlamp, thinkingo

thinkinlamp聚会

本期thinkinlamp应该算是第三期了吧?每一期都有热点,这一期也不例外

只是这一期都集中在百度和微博的爆点上了,都在讲自己怎么优化怎么优化,怎么提高性能,他们也都用图例说明了自己的架构原来是多么的复杂,这些离我们都太远了,其实大家也都明白,PHP能做的事情很多,不仅仅局限于前台,但受限于语言的特性,对于多线程之类的不适合用它来做。也正因此,他们几个都在尝试用其他方式 来避开这个问题,让刀用在刀刃上。

其中有一点就是扩展的问题,百度的人在认为扩展能不用就不用。而鸟哥则认为合理的利用扩展可以有效的提高 性能

然后就是另外三个让我有兴趣的话题了:hm的全文检索/老高的开发规范/梁枫的PHP在web之外

hm的全文检索我是用过了,性能上还是不错,只是当时我的需求是任意字符都必须要能够出搜索结果,但是基于分词的话,就没有办法这么准确。所以,有时候就很纠结。。

老高的几个规范其实在开发中也已经遇到,但有时候真的是为了赶时间就忽略 了这些,不过,在review的时候,偶尔会对这些问题进行修复,但不是每次都保证一定能发现问题,如果到后期遇到了,恐怕就真的很难再改了

梁枫的在WEB之外,是真的让我耳目一新, 无论是直接读ttyACMD之类的文件来使得用PHP与其他设备交互,在linux中,所有的一些都是文件,所以什么都能操作,这点就比windows方便很多。梁枫演示的,用PHP在屏幕画图,视频播放器等功能,真的让我感觉PHP有很多功能没有开发出来。不要忽略了PHP在其他方面的作用。事实上,我就经常用PHP来做运维工具,毕竟用PHP写脚本,对我来说,比shell/bash之类的快很多,而且功能也更强劲

------

顺便,中午的时候,居然有演出,四位朋友的友情演出,才让我突然想起,原来今天是家驹的忌日。从第一次听他的歌到现在居然都快20年了,家驹走好

------

今天的分享中让我记忆犹新的就是几个:1、规范一定要能落地;2、尽量用技术来支撑规范;3、开发的时候就最好把安全都先考虑好;4、PHP能做很多事,就看你敢不敢想

性能有时候虽然重要,但我还是觉得,如果能够加速迭待,那才是更好的。准备开始尝试下一个项目中使用yaf了。理由真的有几点,一是纯C框架,效率有上升,2是有PHP的复刻版,即使真的装不了扩展,也能用这个复刻版

YAR,YAC都还可以考虑,先忍着点。。。。yar因为RPC的不是每个项目里都能够用得上,YAC的话,如果不是因为他无锁,都不太想用,但是又太新了,也不是每台机器上都能使用,所以就先不作考虑了,不过可以尝试在自己的项目里小小的应用一下。。。

鸟哥的扩展太多了。。。小心的用,哈

Tags: thinkinlamp

thinkinlamp 聚會

請不要介意我用的是繁體字。。。

好久沒有參加過聚會了,這次架構師大會怎麼著也得參加,於是我買了門票希望能夠聽到一些不同的東西。雖然最後由於時間由於各種安排,我有一些期望的沒有聽到,但還是聽到了一些比較有興趣的東西。
一、贊助商
為什麼要提這個?畢竟現在各種社區為什麼舉辦不起來?原因有很多,其中有一部分就是因為沒有錢,你想啊,租場地要錢、租設備要錢、錄像要錢,什麼東西都是 靠錢來支撐。如果人來得少了,大家出的份子錢還不夠付付場地費啥的,這時候你也不能讓人加錢吧?如果人來得多了,原先準備的小場地可能就不夠用,或許就會 有人感到不滿意,甚至以後就可能不願來參加。
如果有錢,再加上一群有激情的人,這樣的社區就能夠延續下去,也只有這樣,社區才能延續下去。當然理想情況下,社區應該是自己能夠造血,而不是靠別人來輸血,只有自己能夠造血了,對於外在的壓力才會減輕。
所以,感謝這次的贊助商,也正因為他們,我們才有機會聽到這些知名人士或者說有才華的人給我們的技術分享

二、技術點
大概是因為thinkinlamp舉辦的緣故,所以大家基本上都是講的php相關的技術點。也正因此,更容易被大家所接受和理解。當然今天的技術點並不是 完全與PHP相關,畢竟這是架構師大會。可是誰又能真正的描述什麼是架構師呢?軟件架構師、系統架構師等都能稱為架構師,而今天的分享就幾乎都包含了這些 內容。
1、張爾寧:安居客的架構變遷。張爾寧講的幾點正好是我關注的,搜索和圖片存儲,後期又補充了一些代碼部署和數據統計、數據監控、系統監控等
    搜索用的是solr,以前沒有關注過,以後會稍微看看。但圖片存儲這一塊確實是我關心的,雖然我的量肯定沒有安居客大,但我每天也會產品將近2G左右的圖片,嗯,這幾乎是指原圖。如果再算上縮略圖等,那至少也是3G左右,雖然增長幅度不高,但畢竟也在緩慢增加。100天下來,也有300G左右的數據了,雖然磁盤不值錢,但流量值錢啊。再說了就算不值錢,多少塊硬盤也經不起這樣折騰啊。於是它的圖片的存儲方式我就相對比較關注了(我這裏不介紹,事後應該有PPT,大家可以圍觀,否則我這裏就會有太多話想說了)。
     然後對安居客的一些小產品和小功能有一些想法。我不知道現在有多少公司會向安居客這樣,因為使用了solr,所以又額外做了一些solr的管理程序;因為要部署代碼,甚至實現了一些簡單的github的界面;為了要管理xxxx,最後又實現了一引起xxx的管理軟件;其實我挺羨慕安居客的,至少他們的頭願意看到他們折騰也願意讓他們折騰。有一些boss就無法理解,為什麼不把本職工作做做好,做一些一個星期只能使用一兩次的WEB管理程序。這其實是很多公司的通病。不講了,再講就變成發牢騷了。不過,這些小工具的實現確實簡化了很多工作,所以我也只能是羨慕:人多啊,人多了想做什麼事情的時候都有人做。 人少的時候,事情都做不完,怎麼有空做這些東西?

2、周愛民:架构表达方法中的界面及其原则。周愛民是一個名人,我一直有訂閱他的博客,只是這兩年更新的少了。他的書除了delphi那本沒有看過外,其他的都算是看過了。今天是第一次看到真人,有點失望,長的不太象大師(開個玩笑)。不過他講的東西就是一個軟件架構師在做的事情了。怎麼樣讓架構能夠適合更多的變化。用aimingoo的話來說,架構橫切、豎切、外包圍 都是一種方法,每種方法都各有優劣,只是現在橫切用的比較多一點。(橫切:假設架構是一個正方型,橫切就橫過來一刀,一些基礎構架,一些是應用核心,希望沒有理解錯)。
   周愛民還提出了一些觀點:
    1.框架和库的区别:框架有明确的系统原则和模块原则
    2.服务和层次化理论:服务是一种“库”、需要解除一些逻辑依赖
   當然在提出這些觀點的時候,他是拿Erlang中的一些編程規範來說的,我記得最清楚的就是:盡量少用防禦性編程。
    不可否認,很多時候爛代碼都是從防禦性編程裏產出的。

3、程輝:LAMP in Cloud --- 新浪SAE架构与设计。這個確實是我今天比較感興趣的話題之一。因為在沒有用SAE之前,自己也嘗試對PHP做過簡單的封裝,讓他僅用來跑一個小項目,而可以忽略其他的平臺因素。在今天看來,這種做法其實並不是特別可取,因為它犧牲了可擴展性。不過在5.4的時候,PHP也能夠自己就能夠實現成一個小型 Webserver,所以以前的想法又可以付諸實施了。
    當然新浪SAE不可能這麼簡單,否則它今天就不可能做在這裏講解了。SAE的早期版本只是實現了一個php的runtime,只是為了這個runtime的安全,他們在上面又加上了zend sandbox和http sandbox,各種各樣的沙盒,使得runtime被攻擊的概率減少了很多。說白了,又有點象java的JVM吧,只是JVM又沒有phprumtime靈活。為了避免因為沙盒帶來的影響,sae又模擬實現了很多東西,比如curl庫(這個在早期的版本中是絕對不支持的,經歷了好多版本後才有這個支持),SAE也提供了一些基本的類庫:圖片處理、LBS、郵件發送、memcache、RDC、Counter、KVDB等等,這些小功能的實現使得用戶在遷移的時候能夠將問題最小化。
嗯,我就將yii做了一些簡單的二次開發,使得它支持SAE,我擴展的yiiforsae與另一位朋友的yii4sae不太一樣。將程序遷移到SAE平臺上最大的問題是兩個:1、上傳2、存儲3、緩存,其他的使用都差不多。因為SAE基於SVN,所以在它的項目裏就不支持通過程序生成文件,生成在項目目錄下。只能使用STorageWrapper將文件寫入到存儲中去。就這個比較繁。
SAE還對.htaccess進行了重封裝,只支持一些基礎功能,這些也足夠了。
SAE對我最大的啟發提10個版本庫。這個在SAE第一次推出的時候就有了,非常實用,因為你可以在兩個版本庫之間隨意切換,即,你在v2.xxx.com上進行開發,當測試完成後,將代碼的默認庫設置為v2即可,只要操作一下鼠標就完成了。如果發現有重大問題,繼續點一下鼠標 。一切就是這樣的簡單。
SAE宣傳的就是穩定、安全、保密。陳輝說了,如果你不放心,你可以上傳ZG處理過的代碼。

4、陈思儒 :《AMOEBA(变形虫)的架构以及使用》。說實話這個話題我的興趣不是很大,我並非說陳恩儒的東西不好,而且這個玩意大家現在都在玩一個思想。如果真要說,那SAE的RDC已經有它的類似效果了,當然可能性能不如它。不過在目前變形蟲 還不穩定的基礎上,相信沒有多少人願意當小白鼠。
    不過它的一些策略、處理流程都是可以值得借鑒的。話說,我也沒有覺得lua都很難學吧?
    amoeba的一個缺點在於,因為他支持了多庫多表的即時查詢,所以,對於聚合類的函數,就無法支持了。
   當然,尺有所短,寸有所長,思想是可以用來借鑒的

5、潘曉良:百姓网的“非典型”架构之路。這個分享也是我感興趣的。自從第一次知道客齊集後,後面對於它們的關注就相對比較多,只是後來突然消失了不少時間。百姓綱介紹中說他們的代碼是越來越少越來越少,現在只有7萬行不到了。而在之前的分享中張爾寧說他們的代碼有數十萬行代碼了。百姓網的代碼卻還在精簡(這不正是持續重構嗎?)潘曉良說了一點我非常受用:讓用戶盡可以快的打開網站。這點非常重要,現在很多公司為了好看,大量的CSS加上大量的圖片,使得在訪問的時候光這些圖片和CSS的加載就消耗了好多時間,他們怎麼就沒從用戶角度 想?
    潘曉良介紹百姓網的架構變遷時用了四個詞做代表:遷移、減少、增加、平衡。當然前面兩個是百姓網的特殊歷史原因所造成的就不做多提了。增加,怎麼增加,對我們來說就很關鍵了,要知道程序不是說你加一臺服務器就自動將性能提升1倍了,要改很多東西。雖然潘曉良沒有提,但,因為他們從最多開始就是40臺左右的服務器,相信這些問題在初期就已經被處理或者已經遇到過了。後期這些都不是問題了。
順便說一下,百姓網才18個工程師。糾結啊,18個人做了這麼多的事情。
潘曉良還提了一下,說是百姓網並沒有用了一些多麼高深的架構,相反他們的WEB只有10臺,DB6、7臺,搜索好幾臺。並沒有多麼複雜的架構,他只是很得意說,他們的負載均衡是硬件的,用的很爽。
最後他還是總結了一下:架构是对目标的极致的最求。確實,架構不是越複雜越好,而在對極致的追求中所掌握好的平衡。

三、嘉賓致辭
幾個嘉賓的致辭也很有意思,時間都比較短,除了安居客的倪军是以講故事的方式介紹了某個架構師的成長歷程,其餘的幾位都是在介紹自己的產品。比如 海丁網、比如愛可生,嗯,我想了想,是啊,人家都贊助了,怎麼也得讓人家介紹一下自己的產品吧。再加上時間也不長,也能夠接受。我在這裏就不多談了。

四、隨想
嗯,我還是不太喜歡互動,雖然在周愛民的提問上有想過要回答那個為什麼傳入對象而不是ID,帶來的後果。其實從當時的PPT上可以很簡單的看出,那個函數大致是這樣:checkXxxxFromCompany,但結果,傳遞進去的是一個pueOrder對象。雖然在函數中是取得了這個pueOrder.getCompanyId(),但這本身就與設計不符。
不過,不喜歡互動好象是程序員的通病。很多人都不太喜歡交流,不知道自己想要說些什麼,也不知道如何將自己的想法傳達給別人,這確實是需要鍛煉的。
在結束的時候套用一句很早的臺詞:相聲(演講)是一門語言藝術。要想掌握好還是很有難度啊。

Tags: thinkinlamp

转老王:PHPCheckstyle代码审计与Subversion钩子脚本

之所以要转这一篇文章,是在于有人在THINKINLAMP的googlegroup里提问,说是怎么在svn提交的时候对phpdoc进行检查,需要让他们强制写注释,否则就不让他们提交,于是我说了是在老王的博客上。但后来我看了一下老王新的博客,huoding.com,这篇文章不在(没有迁移到新的博客中)。所以我重新在本地复制了一下他在百度博客里的文章。
原文来自:http://hi.baidu.com/thinkinginlamp/blog/item/17476d22661ee6a94623e8d7.html

PHP代码审计方面的软件越来越多了,PHPCheckstyle算是最近比较活跃的一个。通过SVN钩子脚本的方式来调用PHPCheckstyle,可以强制代码必须符合预先设定的编码标准(比如PEAR编码标准),有助于在多人合作项目中提高代码整体质量。

PHPCheckstyle的设置:

安装真的没什么可说的,属于接插即用型的,唯一需要设置的就是config目录下的配置文件:缺省使用的是default.cfg.xml,你可以编辑它,按照官方文档适当的增减规则。不过PHPCheckstyle项目诞生时间短,不够稳定,截至0.8版本为止还有不少问题,使用前最好逐条规则进行测试。

最简单的运行方法如下:

php run.php --src /path/to/file

这样的话会生成相关的html文档,如果你想直接输出的话,请使用:

php run.php --format console --src /path/to/file

更多选项可以自己看帮助(php run.php就可以查看相关帮助)

Subversion钩子脚本:

下面设置钩子脚本,具体点说是前置钩子,也就是:pre-commit,通过钩子检查后才被允许提交到版本库。只有添加或更新的文件是需要检查的,如果是 要删除的文件,则没有必要检查;还有一个问题,PHPCheckstyle只能检查具体文件的内容,而在提交之前,我们想要检查的文件还不存在,所以我们 得生成一个临时文件,检查完再删除,另外,在生成文件时要注意其唯一性,免得多用户一起提交时发生冲突,注意事项了解的差不多了,可以写钩子脚本了:

代码(at pastebin.com):

01 #!/bin/bash
02
03 REPOS="$1"
04 TXN="$2"
05
06 PHP="/usr/local/php/bin/php"
07 SVNLOOK="/usr/bin/svnlook"
08
09 RUNSCRIPT="/path/to/run/php/script"
10
11 CHANGED=`$SVNLOOK changed -t "$TXN" "$REPOS" | grep '^[U|A]' | awk '{print $2}'`
12
13 for FILE in $CHANGED; do
14     if [[ "$FILE" =~ \.php$ ]]; then
15         TEMPFILE=`mktemp`
16         $SVNLOOK cat -t "$TXN" "$REPOS" "$FILE" > $TEMPFILE
17         MESSAGE=`$PHP $RUNSCRIPT --format console --src $TEMPFILE | head -n -2`
18         if [ ! -z "$MESSAGE" ]; then
19             rm -rf $TEMPFILE
20             echo "$MESSAGE" | sed -e "s|$TEMPFILE|$FILE|" 1>&2
21             exit 1
22         fi
23         rm -rf $TEMPFILE
24     fi
25 done

关于Shell,如果有不清楚的可以自己搜索一下,网上有很多类似的文章

钩子脚本还可以做很多事情,比如核对PHP脚本语法(php -l),而且通过管道符不用生成临时文件:

MESSAGE=`$SVNLOOK cat -t "$TXN" "$REPOS" "$FILE" | $PHP -l`

运行后,不用判断MESSAGE是否为空,而是根据退出状态来判断脚本是否有语法问题:

if [ $? -ne 0 ]

PHPCheckstyle配置和使用多少还是有点别扭,有机会试试PHP_CodeSniffer配置钩子脚本更简单

BTW:发现一个PHP Commit Hooks项目,有点意思,可以看看。
-------
---EOF---
最后,我也下载一份PHP COMMIT HOOKS项目 ,有点意思,可以少写很多了

Tags: svn, checkstyle, thinkinlamp

ThinkInLamp Mysql专场之杨涛涛 的PPT

10月16日 ThinkInLamp Mysql专场中,杨涛涛作了关于MYSQL数据库的优化,最近他在自己的博客上将PPT放了出来,我在这里做一个简单的备份,其实还有SNDA几位DBA的PPT也已经出来了,他们的在thinkinlamp.com 上已经提供下载,我就不再转载了。
我个人相对来说还是比较喜欢mysql的优化,或许对于数据库的设计 我还是停留在程序员的阶层吧。

OK,翠花,上PPT(哦,是PDF版的)
101019150312.pdf

嗯。顺便再附上一份mysql优化的PPT
mysql-introduction-and-performance-optimization.ppt

Tags: thinkinlamp, mysql, ppt

Records:612