幹壞事是進步最大的原動力
Facebook 在「Faster Photos in Facebook for iOS」這篇提到使用 PJPEG 降低流量並且提昇大圖的速度。
實際上我覺得有點詭異，依照說明，降低流量的部份是因為原來有縮圖與大圖：
而現在只要抓一張，所以綜合起來降低了：
但不是每一張都這樣吧？另外是降低了到一定品質所需 image loading 的時間，但這樣看起來用小縮圖應該會更好？雖然 Facebook 的人是以 A/B testing 驗證，但以目前 Facebook 提供的數據並不通，看不太懂他的邏輯...
先丟著吧...
跑 openssl speed ecdh 的時候發現很特別的現象：
Doing 160 bit ecdh's for 10s: 40865 160-bit ECDH ops in 9.99s Doing 192 bit ecdh's for 10s: 34169 192-bit ECDH ops in 9.99s Doing 224 bit ecdh's for 10s: 60980 224-bit ECDH ops in 9.99s Doing 256 bit ecdh's for 10s: 34298 256-bit ECDH ops in 10.00s Doing 384 bit ecdh's for 10s: 9602 384-bit ECDH ops in 10.00s Doing 521 bit ecdh's for 10s: 9127 521-bit ECDH ops in 9.99s
原因是 Google 這篇論文的貢獻：「Fast Elliptic Curve Cryptography in OpenSSL」，開頭就提到：
We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224.
而實際成果：
full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster.
在 OpenSSL 的 CHANGES 也可以看到對應的修改，不只是 NIST-P224 有被改善，其他的 NIST-P256 與 NIST-P521 也都有被改善：
Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs.
頗特別的...
看到「Is TLS Fast Yet?」這個站台，開宗明義就講了，這不是問題：
TLS has exactly one performance problem: it is not used widely enough.
Everything else can be optimized.
下面的表格分析把對於效能影響的分析寫得很清楚，除了軟體外，還包括了各家 CDN 支援的分析，可以參考一下這邊的分析。
不過在 IT 產業實做後效果一直是個疑問。而 2014 年年初時，有人寫文章拿出來討論，並且給出負面的結論：「The Open-Office Trap」。
主要是因為開放空間帶來無形的壓力，同時也容易被干擾：
In 2011, the organizational psychologist Matthew Davis reviewed more than a hundred studies about office environments. He found that, though open offices often fostered a symbolic sense of organizational mission, making employees feel like part of a more laid-back, innovative enterprise, they were damaging to the workers’ attention spans, productivity, creative thinking, and satisfaction. Compared with standard offices, employees experienced more uncontrolled interactions, higher levels of stress, and lower levels of concentration and motivation. When David Craig surveyed some thirty-eight thousand workers, he found that interruptions by colleagues were detrimental to productivity, and that the more senior the employee, the worse she fared.
另外對於健康方面，開放空間互相感染的問題：
An open environment may even have a negative impact on our health. In a recent study of more than twenty-four hundred employees in Denmark, Jan Pejtersen and his colleagues found that as the number of people working in a single room went up, the number of employees who took sick leave increased apace. Workers in two-person offices took an average of fifty per cent more sick leave than those in single offices, while those who worked in fully open offices were out an average of sixty-two per cent more.
而最近 (2014 年年底) 又被提出來，基本上是引用 2014 年年初那篇文章的負面分析：「Google got it wrong. The open-office trend is destroying the workplace.」。
文章裡提出幾個 workaround (因為辦公室改建的成本...)，包括建立 private area：
For one, they should create more private areas — ones without fishbowl windows.
另外也可以從個人習慣改善。如果被打斷了，就先做一些其他的事情：
For instance, when a colleague has on headphones, it’s a sign that you should come back another time or just send an e-mail.
以及利用一些政策避開問題，像是在家工作降低被打擾的機會：
On the other hand, companies could simply join another trend — allowing employees to work from home. That model has proven to boost productivity, with employees working more hours and taking fewer breaks. On top of that, there are fewer interruptions when employees work remotely.
不過這些方法偏向 workaround，如果辦公室可以在規劃時就避開的話會更好，像是這樣：
Puffin Browser - CloudMosa - 辦公室座位區 @ wens的相簿 :: 痞客邦 PIXNET ::
維基百科基金會的人發表了將 PHP 換成 HHVM 後的成果：「How we made editing Wikipedia twice as fast」。
可以看到編輯存檔時間大幅改善：
另外是已登入使用者 (通常是經常參與編輯的使用者) 的頁面產生時間也大幅改善：
另外帶來的好處是 CPU 使用率的下降：
再來就是看 PHP 7 能追上多少了...
在「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 那篇文章裡面有說明。
可以直接看 GitHub 上的 commit log：「Disable GC when computing deps, refs #3482」。
*/
public function run()
{
+ gc_disable();
+
if ($this->dryRun) {
$this->verbose = true;
$this->runScripts = false;
下面變成祭典了 XDDD
然後依照「Avoid generating duplicate conflict rules by naderman · Pull Request #3482 · composer/composer」這邊的測試 (要看下面的討論)，設 zend.enable_gc=0 會省的更多，效率用倍數在跳的...
因為 Composer 的效率為人詬病很久了，這次有人暴發出來，會讓一群人投入資源找更多 optimization... XD
Netflix 的 Brendan Gregg 在「Linux Performance Analysis: New Tools and Old Secrets」這份投影片裡面給了很多有用的工具。
「先找出問題」一向是解決問題的大前提，在投影片裡提到了很多工具，像是這兩個看起來就很有用：
剛剛把 nginx 換到 ppa 的版本 (目前是 1.6)，然後打開 OCSP stapling 與 SPDY，速度明顯有感覺提昇...
OCSP stapling：
SPDY：
目前有想到而且能處理的都做的差不多了 :p
這份投影片「Performance Tuning EC2 Instances」講了不少 Netflix 在 EC2 上各種調校的經驗。
有些比較一般性，可以用在實體機器上，另外還有一些是在 vm 裡的調校。