Hello,
We use Openfire in production (around 15k concurrent users) with the hazelcast cluster. We have disabled JVM cache for User and Roster.
While presence stanza with available=null is processed on user login, rosters are being fetched twice - one for broadcasting user’s presence to its rosters [PresenceUpdateHandler. broadcastUpdate(Presence update)] and again for probing roster’s presence to logged-in user [PresenceUpdateHandler.initSession(ClientSession session)].
As we have disabled Roster cache, we have to fetch rosters from DB twice. So, there is a scope for optimisation here. Please consider the same.
We are using hazelcast cluster of 2 nodes. Our cache size is around 80 Mb, which is consuming around 250-300 Mbps in syncing JVM data. Our rosters size is huge, enabling Roster cache will consume very high network bandwidth which we can’t really afford.
That is … large, to a point that it makes me wonder if the most optimal solution for whatever problem you were trying to address was implemented. This is so far from the expected usage patterns of Openfire that I don’t think that optimization for such a path would benefit the community much. I suspect that there is little interest from people volunteering their time to work on this. You might want to turn to one of the professional partners, if you want to see this optimization being realized.
Thanks for replying and for your suggestions. We look forward to solving high network bandwidth usage problem first (as only 80Mb of cache resulting in 250-300 Mbps bandwidth exchange seems unreal), then we might move in a direction to start caching the rosters.