1. 程式人生 > >特依依|專注J2ee開發、Solr、Solr4、Slorcloud、Lucene和大資料的挖掘技術

特依依|專注J2ee開發、Solr、Solr4、Slorcloud、Lucene和大資料的挖掘技術

 D.Maradona²º¹²(307487602)  13:28:56
請教solr的併發能力,最好有資料量化說明
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:30:43

這個是我做的一個簡單併發測試
報告
露露的功課(1982118)  13:32:07
這個報告不錯,但是還不夠清楚
說明你solr的架構
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:32:25
簡單做了個 自己心裡有點數就夠了
√鎽い1cだ仌(113757943)  13:32:48
用什麼測試的啊
loadrunner?
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:33:11
自己寫的多執行緒 
√鎽い1cだ仌(113757943)  13:33:12
還與伺服器配置有關。
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:33:20
模擬出來的
√鎽い1cだ仌(113757943)  13:33:22
哦。
北京-哈哈-6(383273828)  13:33:42
solr 你給多大記憶體他就吃多大
但會 留出1-2G來
不會全吃
露露的功課(1982118)  13:34:21
你的資料量是多少
北京-哈哈-6(383273828)  13:34:23
我以前給 25G 結果 高峰時 用到 23G
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:34:28
我16g  機身用記憶體7個g  剩下的 都被solr吃了
北京-哈哈-6(383273828)  13:34:37
我給45G 記憶體高峰時 用到42G
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:34:41
4700w資料
北京-哈哈-6(383273828)  13:34:45
我是 30W併發
3個核心
露露的功課(1982118)  13:35:03
是一個機器嗎
北京-哈哈-6(383273828)  13:35:04
一個核 8百多萬
一個核 10W
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:35:23
恩恩 solr cache相當給力
不怕高併發
北京-哈哈-6(383273828)  13:35:35
還有個 核 2千萬
露露的功課(1982118)  13:35:39
測試的時候把cache去掉
裸測
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:35:53
裸測沒意義
露露的功課(1982118)  13:35:57
2000萬資料,我全放記憶體,效果不太好
北京-哈哈-6(383273828)  13:35:58
我單機 抗住幾萬萬 使用者
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:36:00
主要就是想用cache
北京-哈哈-6(383273828)  13:36:01
不簡單哇
露露的功課(1982118)  13:36:23
cache測併發不太好
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:36:23
看看高併發的時候 cache機制怎麼樣 會不會記憶體溢位
北京-哈哈-6(383273828)  13:36:28
不使用solr 的cache 效能沒那麼好
D.Maradona²º¹²(307487602)  13:36:38
我自己測試結果 10使用者併發請求 結果反應時間>5秒了 這是不是太弱了?
露露的功課(1982118)  13:36:44
不用cache solr效能不太好
北京-哈哈-6(383273828)  13:36:46
跑 solr 你要想 跑的效能好 機器配置要高
還要寧分散式
才行
露露的功課(1982118)  13:37:16
用facet比較消耗效能
北京-哈哈-6(383273828)  13:37:22

facet確實
露露的功課(1982118)  13:37:37
我這都是裸測的
不用cache
沒有資料切分
資料全部放記憶體,效果都不太好
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:38:10
那你以後也不用cache?
露露的功課(1982118)  13:38:14
3秒,500併發
現在是測試併發,所以不用cache
要不然,達不到測試目的
小莮亽丶獨佔伱旳嫵媚(1804667222)  13:38:49
恩恩 用意不同
露露的功課(1982118)  13:40:02
solrcloud 存在好多問題,自己搞切分是可以,維護稍微麻煩點
露露的功課(1982118)  13:42:23
建議要求效率高的朋友,但是不想用solrcloud的可以看看這個

Azul創新的Zing JVM和無停頓垃圾回收(GC)使Apache的 Lucene 專案開發者開始去研究需要大規模堆的事例(例如為了更快搜索將整個搜尋索引存在記憶體中)。基於全維基百科英文站點的索引記憶體初步測試顯示Zing真正實現了在管理140GB以上堆時不用暫停。Clojure創始人Rich Hickey提到:平衡不可變性以提高併發性和擴充套件性的的編碼和架構策略使Zing JVM能很好地支援無任何中斷或停頓的、持續的高物件分配率。Azul將Zing JVM開源,這為社群作出了傑出貢獻