memsql 是乙個記憶體資料庫,很多人對memsql的效能有很大的誤解。以下是mysql,mysql+handler,memsql效能測試的對比。
參考**:
在執行測試前必須首先說明一下本地的虛擬機器測試環境：
mem：2g
cpu：1 core
os：centos 6.0
配置整體較差，其實是不適合做db環境的效能測試的，尤其cpu/記憶體都不夠強，對於測試memsql這種恰恰很依賴cpu的應用其實是很不公平地，可是手頭上暫時未找到裝了centos6以上版本的實體機，因此臨時拿它充數。不過測試前我自己心裡也有預期，這個效能表現不會太好，結果只能說僅供參考，其實是不具備實際意義地。待過段時間有了空閒資源會考慮再做對比測試。
這裡先按照普通流程走一遍，大致看一下對比，先看看查詢mysql資料庫時的效能：
測試通過handlersocket外掛程式訪問mysql庫時的效能：
最後來看memsql的表現：
從效能對比上來看，比標準的sql方式查詢mysql資料庫確實要快一些，但效能提公升沒有想象的那麼多，對比handlersocket外掛程式方式訪問，甚至效能還要差很多的。
但是開頭也說了，虛擬機器環境不太適合做db的測試，這裡的結果僅供參考。考慮到曾經在標配8核48g的linux pc上測試handlersocket，峰值qps能到10w，以此對比計畫，估計好一點的機器上，memsql的qps達到數萬應該是沒有問題的。
不過從上面這個結果對比實際上還是能看出些許差異地，我們注意到，這三個測試中，cpu佔用率方面，傳統sql方式查詢是最佔cpu資源地，這與它執行時需要做大量sql解析有直接關係，其次就是memsql方式，handlersocket的cpu佔用率最低。在系統負載方面，也有相同的結論，所以，我目前傾向於認為，memsql的效能應當是不及mysql服務載入handlersocket外掛程式的表現地。
不過，由於memsql對於mysql的良好相容性，從mysql轉換成memsql的實施成本很低，幾乎就是運維人員安裝好軟體，同步好資料就行了 ，我想在某些場景還是有其大展拳腳的舞台地。現在比較令人困惑的是memsql究竟會如何定位自己，從目前公開的資訊來看，它還是想走商業化路徑，在當前推出的版本中，開發版本可以免費使用，但是記憶體最多只能使用10g，試用版本倒無記憶體的限制，但是只有30天的試用期。做為乙個後來者，倒是可以給他些時間，看看未來的表現如何。
****************************************==
MemSQL初體驗 3 效能測試
在執行測試前必須首先說明一下本地的虛擬機器測試環境 mem 2g cpu 1 core os centos 6.0 配置整體較差，其實是不適合做db環境的效能測試的，尤其cpu 記憶體都不夠強，對於測試memsql這種恰恰很依賴cpu的應用其實是很不公平地，可是手頭上暫時未找到裝了centos6以上...
Hypertable初體驗之效能測試
為了最大程度上測試ht的效能，簡單的選擇了隨機的寫入測試，主要是採用了random write test的測試程式。該程式主要是隨機的向乙個cf中寫入定長的資料，預設的cf寫入資料是1k位元組，rowkey約為24位元組，具體可以看 採用自動mutor的方式來提交資料。為了進行一些基本的測試，重新拿...
Android測試之Monkey初體驗
monkey是android中自帶的用來進行壓力測試的乙個命令列工具。正常crash 程式崩潰 anr 程式無響應 1.手機與電腦進行usb連線，並在開發者選項中選中usb除錯 2.確認手機與電腦連線 開啟cmd命令列或者使用android studio的朋友可以開啟terminal檢視，輸入adb...