用 Psalm 掃出 PHP 有問題的程式碼

Psalm 的 slogan 是「A static analysis tool for PHP」,由 Vimeo 發展並開放出來的軟體:「vimeo/psalm」。

目前是 v0.3.71,所以需要 PHP 5.6 以上才能跑:

  • v0.3.x supports checking PHP 5.4 - 7.1 code, and requires PHP 5.6+ to run.
  • v0.2.x supports checking PHP 5.4 - 7.0 code and requires PHP 5.4+ to run.

Psalm 主要的目標是找出哪邊「已經發生錯誤」,而不像其他幾套的目標是「預防」,這樣可以避免過高的 false alarm...

兩個 gperf...

翻資料的時候覺得怎麼跟印象中的不太一樣,多花些時間翻了一下,發現原來有兩個東西同名...

一個是 GNUgperf,給定字串集合,產生 C 或 C++ 的 perfect hash function (i.e. no collision):

GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.

另外一個是 Google 弄出來的 gperftoolsmalloc() 的替代品以及效能分析工具:

gperftools is a collection of a high-performance multi-threaded malloc() implementation, plus some pretty nifty performance analysis tools.

/usr/bin 下的工具介紹

Adventures in /usr/bin and the likes」這篇介紹了 /usr/bin 的各種工具。即使是在 FreeBSDLinux 下面混了許多年,還是看到了不少好用的工具,值得慶幸的是,至少有一個章節 (Misc) 還算熟悉...

OS 的 chrttaskset 看起來再壓榨效能的時候應該可以拿出來用。用
peekfd 不如記 strace 比較萬用...

Debugging 的 addr2line 則是學到了一招,對於還是 segfault 看起來應該會很有用...

後面 Data Manipulation 的部份其實都很值得再拿出來看,尤其是這一章的東西,沒在用常常會忘記...

Linux 下各種效能觀察工具

Twitter 上看到整理出來的:

大圖:

找時間操練一次才會記得... 不過話說回來,出現 @FreeBSDHelp 也是頗有趣的 XD

Adobe Typekit 對 PageSpeed 的妥協

Adobe Typekit 是個收費的網頁字型服務,為了讓變更可以儘快生效,用了比較短的 cache time:

We use a short cache time for the kit JavaScript so that you can update your kit (for example, adding fonts, or changing the list of allowed domains) and have your changes live in a reasonable amount of time.

但這也造成了不少人抱怨 Google PageSpeed Tools 會扣分,而實際上也的確降低效率 (因為你不需要天天改設定):

Adobe 給了妥協的方案,你可以選擇使用更長的 cache time,從本來的 10 mins 變成 1 week:「Improved caching for kits: Opt for longer cache timeout」。

這個選項使得 Google PageSpeed Tools 不會扣分,也讓效能再更好一些。

用 jQuery Audit 在 Google Chrome 的 Developer Tools 看到 jQuery 的資料

在「jQuery Audit lets you analyze jQuery from Chrome Developer Tools」這邊看到 jQuery Audit 這個 Google Chrome 的套件。這個套件讓你在 Developer Tools 裡看到 jQuery 的資料:

在大家都用 jQuery 操作的情境下,這個套件超好用...

用 npm 取代 Build Tools (像是 gulp 或 grunt)

這篇「How to Use npm as a Build Tool」教你如何用 package.jsonscripts 取代 gulp 或是 grunt 這類 Build Tools。

文章裡面可以看到各種奇技淫巧都出現了,dependency 的部份用 recursive 解決 (npm 內部自己再呼叫 npm 執行),stream 的部份用 pipe 解決 (這個到是很自然),然後用外部程式掛進來處理 watch 與 livereload,甚至還出現可以自己寫 js 檔案呼叫的方法... XDDD

無所不用其極!反正我就是不要用 gulp 與 grunt... XD

可以欣賞一下怎麼做的...

用 perf 追蹤系統狀態

在「Make Your Program Slower With Threads」這邊看到的工具:「Linux kernel profiling with perf」。

Ubuntu 上的安裝方式是安裝 linux-tools,不過我的機器上是安裝 linux-tools-lts-raring

先從比較簡單的 stat,基本的用法很簡單,後面接指令就可以了:

perf stat ls -al

這樣會出現基本的執行狀況,像是這樣:

 Performance counter stats for 'ls -al':

         11.236723 task-clock                #    0.703 CPUs utilized          
               341 context-switches          #    0.030 M/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
               453 page-faults               #    0.040 M/sec                  
         8,186,524 cycles                    #    0.729 GHz                    
    stalled-cycles-frontend 
    stalled-cycles-backend  
        10,366,309 instructions              #    1.27  insns per cycle        
         2,122,560 branches                  #  188.895 M/sec                  
            36,979 branch-misses             #    1.74% of all branches        

       0.015977493 seconds time elapsed

更複雜的用法在 Tutorial 那篇文章裡面有說明。

Netflix 在 USENIX/LISA2014 上講「Linux 效能調校」

NetflixBrendan Gregg 在「Linux Performance Analysis: New Tools and Old Secrets」這份投影片裡面給了很多有用的工具。

「先找出問題」一向是解決問題的大前提,在投影片裡提到了很多工具,像是這兩個看起來就很有用: