做項目的過程中,發現一次遠程鏈接數據庫的耗時大概是300ms~400ms,切身體會到了前輩們經常說的減少鏈接的重要性,用了緩存后頁面的打開時間從1.5s減少到400ms
前提:
那么來說一說正題,web中多標簽多條件篩選的設計.有兩個思路:
一種是通過頁面刷新來獲取數據
一種是通過ajax來異步獲取數據
思考:
大的方向兩條,分支很多,想搜索一下有沒有最優方案,似乎找不到.
spike:
//js來獲取用戶點擊的標簽,拼裝url,再用window.location.href=url來跳轉.
a標簽在當前url后加參數,之后用js來改寫a標簽的herf.
開發到一半從總部傳來的消息:不要刷新頁面,用異步加載.然后引用一下我老大的反擊:
ajax的這幾個缺點：
1，SEO不識別
2，無法給出某個城市的URL，因為URL都是一致的（當然可以用#實現。。。）
3，如果服務器響應超過2秒，頁面感覺是假死。。（當然可以搞loading。。。）
4，每加一個參數要改很多JS。。。就是要寫很多腳本來兼容這些點。。維護麻煩。。
當然要用我也不排斥。。。就是不喜歡。。
反省:
請看如下代碼:
public function url_format($level, $district, $lev, $dis, $rank)
{
foreach ($level as $k => $v) {
$level[$k]['url'] = '?lev=' . $k . '&dis=' . $dis . '&rank=' . $rank;
}
foreach ($district as $k => $v) {
$district[$k]['url'] = '?dis=' . $v['id'] . '&lev=' . $lev . '&rank=' . $rank;
}
}
不得不承認這是一種很笨的方法,窮舉對於編程來說既是大忌同時也是開發速度最快的選擇,在沒有考慮到窮舉這一個選項之前已經開始准備使用遞歸的方法來生成url,然而在后期優化的時候,遞歸也是一個思考的方向.
再來說緩存
之前提到過,一次遠程IO大概是400ms左右,與數據量大小成正比,初次使用緩存優化嘗到了甜頭,然后死在了所有人都犯過的錯上,老大對我估計是不止第一次不知道多少次的說出了這樣的話:
你在用緩存優化頁面,頁面被你優化的很快,很流暢你很有成就感的時候但是你要注意到一點,你的數據更改不會及時生效,如果你要刪除緩存的時候會不會很難操作
沒錯,我單個城市的緩存達到了五十個以上,包括各種數據的分類以及篩選數據.如果是全國200個城市,那么緩存數量將輕松上千.在測試服我可以用flushall,正式環境呢?
緩存一時爽
在公司沒有一套完整的控制緩存的機制時,濫用緩存是一件非常不理智的行為,優化后的方法:
將每個城市的全部數據放入緩存中,再根據用戶的篩選條件在php中進行篩選.
public function data_filter($paras, $data)
{
$pagesize = $paras['pagesize'];
$start = $paras['start'];
unset($paras['pagesize']);
unset($paras['start']);
unset($paras['city_id']);
foreach ($paras as $k => $v) {
foreach ($data['list'] as $key => $value) {
if ($v != 0 && $value[$k] != $v) unset($data['list'][$key]);
}
}
$total = count($data['list']);
$data['total'] = $total;
$data['list'] = array_slice($data['list'], $start, $pagesize);
//var_dump($data);
return $data;
}
將無用條件unset掉,再將不符合條件的數據unset掉,根據分頁來展現數據.就完成了再緩存中取數據,再php中篩選的過程.這樣的話速度大概慢了200ms左右,不過比起來一大堆緩存key來說..這點時間是值得付出的