api介面響應慢？
sla一直提不上去？
其實這是後端程式設計師想高階必須要跨過去的坎：就是把它優化掉。
那麼這其中到底有沒有套路呢？答案是：有的。
本文將介紹目前正在用並且十分「無腦」有效的這個套路。
首先呢，第一部肯定是在關鍵函式(有db、檔案、複雜計算等操作)的前後，進行時間的記錄。這裡分享乙個前文跟蹤的類trace.php
<?php
class trace
function start($type, $time=0)
if($this->single_mode) else
}function stop($type, $time=0)
if($this->single_mode) else
}function time($type) else
}function log($type)
function logall($prefix = '', $ext = array()) else
if(!empty($log))
}function output($with_endtime = true) else }}
}}
return $output;
}function reset($type = null) else
return $this;
}function enabletrace($exit = true)
}?>
怎麼使用呢？
$trace = loadclass('trace');
$trace->enabletrace(true);
$trace->start('total');
$trace->start('func1');
$this->run_slow_function1();
$trace->stop('func1');
$trace->start('func2');
$this->run_slow_function2();
$trace->stop('func2');
$trace->stop('total');
$trace->logall('咖啡色的羊駝');
$trace->reset();
ps:此類對線上介面產生的耗時基本可以忽略，所以放心用。
既然找到了跑得慢的函式。那麼就開始優化吧。
先說前提：前端已有lvs負載均衡、nginx反向****請求。
首先需要分析為何跑慢了？1.是不是資源層面的瓶頸？
2.是不是快取沒新增，如果加了，是不是熱點資料導致負載不均衡？
3.是不是有依賴於第三方介面？
4.是不是介面涉及業務太多，導致程式跑很久？
5.是不是sql層面的問題導致的等待時機加長，進而拖慢介面？
6.網路層面的原因？頻寬？dns解析？
7.**確實差？？？
8.未知？
對症下藥1.資源緊張，加機器，幹上去，負載均衡搞起來
2.加快取可以解決的問題都不是什麼大問題，存在熱點資料可以將某幾個熱點單獨出來用專門的機器進行處理，不要因為區域性影響整體
3.一方面與第三方溝通介面響應問題，另一方面超時時間注意把控，如果可以非核心業務能非同步久非同步掉。
4.把非核心的業務進行非同步化操作。記住如果**層面是非核心業務，但是會影響使用者感知，需要慎重決定是否非同步。
5.如果是**不良導致加鎖了，盡量優化索引或sql語句，讓鎖的級別最小（到行），一般來說到行差不多了。如果是單個sql跑慢了，需要分析是不是索引沒加活著sql選的索引錯了，索引該加的就加了，該force index也加了。
6.網路原因，需要聯絡運營商一起商量下怎麼解決，單方面比較難有大的優化。
7.**確實差，那也無藥可救了。我選擇狗帶。
通用套路非同步化
API介面響應速度追蹤類
api介面響應慢？sla一直提不上去？其實這是後端程式設計師想高階必須要跨過去的坎 就是把它優化掉。那麼這其中到底有沒有套路呢？答案是 有的。本文將介紹目前正在用並且十分 無腦 有效的這個套路。埋點追蹤分析，找出真兇 首先呢，第一部肯定是在關鍵函式 有db 檔案 複雜計算等操作 的前後，進行時間的記...
PHP專案響應速度優化
專案可優化範圍很廣，這裡我們只討論php程式本身的加速。開啟opcache。zend引擎每次都會把php 解析成opcode，開啟opcache後，會快取opcode。伺服器的gcc編譯器使用4.8 zend處理opcode部分的優化gcc4.8 才支援，官方稱會帶來5 效能提公升。跟第一條的opc...
PHP專案響應速度優化
專案可優化範圍很廣，這裡我們只討論php程式本身的加速。開啟opcache。zend引擎每次都會把php 解析成opcode，開啟opcache後，會快取opcode。伺服器的gcc編譯器使用4.8 zend處理opcode部分的優化gcc4.8 才支援，官方稱會帶來5 效能提公升。跟第一條的opc...