思考:系统的瓶颈到底在哪儿，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/

就是加内存也没什么卵用。