思考:系统的瓶颈到底在哪儿,redis的作用?

1.现在openfire确实已经到了瓶颈,然后根据网上优化方案,说是把session移入redis会有比较可观的改善。

但是问题来了,user的session在openfire里面是存在一个Concurrentmap里面的.也就是说这玩意儿也相当于一个缓存。
并没有说去查数据库,其实查数据库是很少的。那么把这个session从Concurrentmap移入redis当真有用吗?都作为一个缓存,走redis还得专门走一次网络,无论redis自己的协议亦或是内网传输有多快,都不可能比存在自己jvm里面的快吧?
之前跟老大讨论了,redis肯定有的一个好处就是,如果我把session、cache等其他一系列cluster需要同步的东西吃透了,那么把这些所有的存入redis,redis相当于一个中间层,那么之后就不需要集群这个玩意儿了,全去redis取。(之前看过一个数据就是redis单机每秒能处理100W次,某个著名XX说的)这样一来变相实现了集群,之后想加多少节点就加多少节点。
但是老大又告知我Hazelcast集群同步的原理,(其实都一个样)就是来一个,全部分发给其他节点。这种相当于每个节点都存储了所有的会话。这样肯定是比去redis取要快的。
说来说去,其实就是,用redis到底能不能提升容量,openfire自带的集群插件hazelcast已经是很强大了。内部的partition也很NB,用redis按理论来说到时候还更慢。
我们目前的瓶颈应该不在于内存,25G的内存感觉还没用完。到底问题出在了哪儿?
跟同事谈论又说是这个JDK自带的HashMap上了100M就会有问题。这些日子认真琢磨了下HashMap里面的东东,他说的应该就是会出现hash碰撞吧。
然后又发现设置初始值是非常有必要的,(hashmap size*2会引起重新拷贝和重新hash映射,嗯,好像是这个,之后确认下)
之前系统默认是0.25M,飘红后我改成了-1即无限大。现在看来是很不合理的,终于理解之前在openfire国外论坛看到的人家都设置的是一个实际的值。原来是有原因的。
扯远了,但是这些玩意儿说来说去都跟客户端能连接进来没啥关系啊 好像?那到底为什么内存还够的情况下,客户端无法连接进来了呢?(也说不定咱根本没那么多用户,搞这些事都是在大惊小怪呢,谁叫tsung这玩意儿就是测不准呢)
总结下,现在问题是不知道系统瓶颈在哪儿。
1.接下来先把map初始值调好。 MAX = 设置的 * 0.75,好像是这个。这个调好了应该就不会出现以前的会话不停的丢了进,进了丢了。(所以一切都是有原因的。只是你不知道而已,多学啊!)
2.把这个Concurrentmap测一下,看看200M的情况下会有哪些问题,put不进去了吗?
3.JVM监控,看看垃圾回收方面的问题?
4.JVM监控,看看是不是内存不够用啊?
5.fastutil 的map代替JDK的concurrentmap。这个先要看看是否支持并发和有什么问题。
(老大说无比成熟健壮,我还是看看吧,权当学习)
6.继续session、cache移入redis,搞了这么久了,有点成果了,至少弄了之后能懂这玩意到底能不能提升。

有时间多看看并发编程网,
我这问题貌似有点像这个:缓存无底洞问题
http://ifeve.com/redis-multiget-hole/
就是加内存也没什么卵用。

你可能感兴趣的:(JVM内存管理-GC,openfire)