這周工作主要是修改**和調整bug了，目前的思路是放棄skiplist了，因為上週測試了一下基本不靠譜。。。插入效果一般但是讀取效果更差，這一周主要採用以下的三個優化思路
1. 在item中新增乙個為tag的標記位，這個的目的其實很簡單就是優化查詢的效率，當hash有衝突的時候，比較字串的時候先比較tag，注意這個tag是採用不同的hash函式構成的，目的是減少長的字串的比較做的這麼乙個設計
2. 將hash表分塊，分成16個塊，每個hash塊自己維護自己的hash表和lru鍊錶，這樣做的目的其實就是減少了鎖的粒度，能夠在一定程度上提高併發空間，提高併發的效能。
3. 最後乙個優化還沒做完，是將lru的鍊錶做成迴圈的鍊錶，當有元素插入的時候，首先檢測能否分配，如果可以，分配記憶體直接插入，否則的話，採用clock演算法進行替換，這麼做的目的其實就是為了減少get的時候，將lru提到表頭的問題，因為get的訪問其實很頻繁而insert其實相對較少，比例看facebook的乙個調查大約是1:500，所以應當以優化get為主，刪除還是簡單的lazy操作，只標記而不替換，只有在插入的時候上鎖，希望這樣可以提高併發度。
這一周一直再改**，昨天修改好的**讓我今天修改的bug了，一直是segment fault，折騰一天了，這週的總結就這些了。。。我還是趕緊fix bug去。。。下週的話應當可以完成相應的工作。預計效能肯定是有所提公升的，希望能夠達到要求。
周一更新：
分塊的這個hash的優化目前原始的處理是10萬次insert每秒，而我的優化是13萬次每秒，get的話兩個差不多，主要還是和workthread的數目相關，workthread越多我這邊的優化比較明顯，在workthread為20的情況下兩個處理能力都是11萬，但是我把workthread加大之後原始的處理能力稍微下降，而我的則有點上公升，所以今天繼續優化，這週把clock置換演算法新增進去，估計能把get優化下，然後繼續測試吧，看看workthread的上限大概是個多少，看看insert的處理能優化到什麼程度吧。
前端效能優化 六
為了盡快完成首次呈現，我們需要優化下列三種變數 關鍵資源是任何可能阻止網頁眉次呈現的資源。網頁上的關鍵資源越少，瀏覽器在螢幕上顯示內容時必須完成的工作量就越少，對 cpu 和其他資源的占用也就越少。換言之，資源數量 位元組數和關鍵路徑長度相互關聯，但是並不完全相同。例如，您也許無法減少關鍵資源數量，...
memcached效能監控
我給大家介紹了如何在windows平台上部署memecached服務端，如何在.net平台中應用memcached，詳細介紹了兩種流行的客戶端元件的配置，使用 儲存 取值 替換 刪除 快取時間設定等 優缺點等。在我們的測試專案中，主要是針對 單台伺服器 的應用場景。事實上，在我們實際開發中，往往需要...
Memcached效能測試
linux 下 memcached安裝 和 php 開啟 memcached 擴充套件這裡就不多說了，網上很多可供參考，下面對啟動memcached後對 的效能提公升做個簡單的測試，以下是在長沙寫字樓網 啟用memcached擴充套件之前寫乙個測試 header content type text ...