|
測試同學(xué)使用tsung測試openfire時(shí)發(fā)現(xiàn)注冊并發(fā)數(shù)過低，同事經(jīng)過測試認(rèn)為數(shù)據(jù)庫是最大瓶頸，建議將mysql數(shù)據(jù)庫改造成mongo數(shù)據(jù)庫。
首先嘗試改造了ofUser表相關(guān)操作，使注冊邏輯整體走mongo： 改造涉及文件如下： 在org.jivesoftware.database 包下仿照DefaultConnectionProvider、DbConnectionManager創(chuàng)建mongo的相關(guān)Provider和Manager 為了減輕字段映射壓力，使用了morphia，因此，需要?jiǎng)?chuàng)建相應(yīng)的pojo，如ofUser.java 改造所有涉及ofUser表的增刪改查
由于原來為了適應(yīng)多種數(shù)據(jù)庫，所以在其中增加了很多判斷，搞明白邏輯后可以去除這些判斷。 mongo連接方面參考了以下文章： http://www./Linux/2012-01/52150.htm http://www.cnblogs.com/huangfox/archive/2012/04/01/2428947.html http://blog.csdn.net/magicfoxhu/article/details/7568728 openfire數(shù)據(jù)庫相關(guān)參考了下面的文章： http://www./database/1249683.html mongo的api及文檔： http://api./java/2.8.0/ http://docs./manual/genindex/ java操作mongo： http://www.cnblogs.com/hoojo/archive/2011/06/02/2068665.html http://tech.it168.com/a2011/0617/1206/000001206231_all.shtml http://blog.sina.com.cn/s/blog_5d3241cc0100q7yp.html http://www./database/201202/118157.html http://www.cnblogs.com/yuechaotian/archive/2013/02/04/2891416.html http://blog.csdn.net/mengxiangyue/article/details/8957085 使用morphia： http://wenku.baidu.com/view/83b56947a8956bec0975e357.html http://www./watchzerg/archive/2012/09/20/388109.html http://www.cnblogs.com/hoojo/archive/2012/02/17/2355384.html 在尋找的時(shí)候還發(fā)現(xiàn)了個(gè)特好玩的morphia使用者： https://github.com/turbidsoul/turbidsoul.github.io/commit/fe4bcdc7238b24ed06aaf327e3470ced676d1b27 在做pojo的時(shí)候特意研究了下objectid呀~發(fā)現(xiàn)了很多好東東哦~ http://www.cnblogs.com/xjk15082/archive/2011/09/18/2180792.html http://www./database/20120317/319007.html http://blog./html/3511.html ——————————————分割線———————————————————————————————————————————————————————— 改造完成開始性能測試： 數(shù)據(jù)庫插入數(shù)/理論插入數(shù)， mysql注冊基本穩(wěn)定在75% mongo注冊基本穩(wěn)定在30%?。。?！ 震驚了我，mongo的性能怎么可能這么差??！ 趕緊查查mongo性能提升相關(guān)的文檔： http://database.51cto.com/art/201109/293088.htm 第一條：是否建立索引，果然，我并沒有建立索引，而在注冊時(shí)需要先查一下此用戶是否存在再進(jìn)行插入，查詢對索引需求大，建立索引，參考如下文檔： http://blog.sina.com.cn/s/blog_af52238c0101bhno.html 建立username索引，再次測試： mongo注冊率穩(wěn)定在76% 松了一口氣，但是只幣mysql高1%，這可不行，開始監(jiān)控mongo性能，參考： http://www./mongo-mem/1489.html http://www.cnblogs.com/shanyou/archive/2010/10/02/1841348.html http://blog.csdn.net/liubo2012/article/details/8203751 發(fā)現(xiàn)mongo一直處于非繁忙狀態(tài)，高并發(fā)行為并沒有對其產(chǎn)生壓力。只有少數(shù)insert方法執(zhí)行速度超過10ms，但是數(shù)量極少 懷疑代碼或者測試工具有問題，修改代碼： （1）去除邏輯中的query妹紙保留insert，性能沒有提升--》性能與query無關(guān) （2）關(guān)閉性能監(jiān)控，性能沒有提升--》性能與性能監(jiān)控?zé)o關(guān) （3）刪除索引，性能沒有提升--》性能與索引無關(guān) （4）不使用morphia方法使用driver自帶方法--》性能沒有提升，與morphia方法無關(guān) （5）去除db重連邏輯--》性能沒有提升，與此邏輯無關(guān) （6）使用morphia save方法，每1000個(gè)注冊請求，調(diào)用一次--》性能下降，原因：morphia.save并非調(diào)用批量方法，積攢1000個(gè)請求在使用此方法依舊是一個(gè)個(gè)插入，反而增大了壓力。解決：改造成driver自帶insert 批量插入方法，上升至76%，--》與批量無關(guān)，但是批量插入的確比單個(gè)效果更好，（貌似批量操作會有全局鎖問題，需要查看http://blog./uid-26660567-id-4106642.html） （7）增大客戶端單機(jī)連接數(shù)，20改為400，性能無明顯變化，查詢資料：http://blog.csdn.net/jollyjumper/article/details/8553307，增加連接數(shù)反而可能使性能下降。
--依舊原因未知，實(shí)驗(yàn)mongo shell循環(huán)插入10w條。參考： http://www./other-database/383981.html 10w條用時(shí)40s，監(jiān)控mongo性能，返現(xiàn)在使用mongo shell循環(huán)插入10w條時(shí)壓力比tsung 500 并發(fā)高。再次確定mongo應(yīng)對壓力無問題。 無法，開始使用笨辦法：查看數(shù)據(jù)庫數(shù)據(jù)，希望能行數(shù)據(jù)中找到缺失規(guī)律，還真被我找到了??！-- 插入6000條數(shù)據(jù)，前5335條插入無丟失，只丟失5336-6000的數(shù)據(jù)。推測一定不是并發(fā)造成的丟失。 在代碼邏輯的insert語句前打印日志，與數(shù)據(jù)庫數(shù)據(jù)進(jìn)行對比，發(fā)現(xiàn)日志打印數(shù)與插入數(shù)據(jù)庫數(shù)完全相同，再次確認(rèn)與數(shù)據(jù)庫無關(guān)，推測可能是自行修改的mongo邏輯和mysql邏輯不通導(dǎo)致，測試mysql邏輯，發(fā)現(xiàn)打印日志數(shù)與插入數(shù)據(jù)庫數(shù)依舊相同---》確定數(shù)據(jù)庫絕對無壓力。 ————————————————————————————我是無奈的分割線———————————————————————————————— 忽然被告知，測試同學(xué)配置的tsung有問題。啊啊啊啊啊啊啊==。。。明天使用同事自己做的壓測工具。。
其他參考文檔： 關(guān)于Mysql和Mongo的性能測試http://blog.sina.com.cn/s/blog_591888d50101jx67.htmlOpenfire 性能優(yōu)化 http://blog.csdn.net/blade2001/article/details/9094331 java鏈接mongo http://blog.csdn.net/freebird_lb/article/details/7470384 ________第二天的分割線—————————————————————————————— 使用了asmack組件提供的接口，瞬間創(chuàng)建多線程施壓測試，測試環(huán)境(Intel(R) Xeon(R) CPU 2.13GHz ,內(nèi)存：4139668 kB，64位) mongo最長消耗時(shí)間是mysql最長消耗時(shí)間的2/5左右。 mongo在高并發(fā)注冊情況下，成功率遠(yuǎn)高于mysql，具體數(shù)據(jù)如下：
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
