What do you mean all users are cached. I need a seamless experience for my end-user. I mean even if Openfire crashes, Clustering or some other fault-tolerant technology, should help me achieve a seamless experience for the end-user.
i.e He shoudls still be able to do IM without realizing that a crash or something wrong has happened.
Is this possible with 200,000 users.
Your answer says 200,000 users but i would be happy with atleast 20,000-50,000 users as long as Openfire is stable. Then its just a question of deploying more servers for more users.
I mean, to get good performance I had to do a first pass and log in each and every user in order for them to get cached. If Openfire has to read users from DB, the performance drops sharply. I tested this with a single server using PostgreSQL, ymmv.
Clustering will help by caching sessions and such, but there are clients (like Apple’s iMessage - or whatever it’s called) that just won’t do SRV lookups. These will have no option, but to log in again. Unless you’re prepared to work some low-level networking magic.
I am still very new to XMPP and OpenFire and even moderately familiar with Java. So I dont understand all the terminologies. Hope to get there in the next few weeks.
Can you explain what you mean by low-level netowrking magic. Are you talking about BSD socket programming at a TCP/IP level. What kind of networking magic are you talking about?
I heard that a company called Nimbuzz uses OpenFire and they claim to have 150 million users. So I dont know how they are handling such a large user base with OpenFire.
I mean, if the client desn’t do DNS SRV lookups, it will use an IP to connect. If you want the server to change, but at the same time the client to continue using the same IP, you’ll need a solution that’s lower level than IP. I have no idea what that solution would look like.
Thanks for the screenshot, we are running similar tests but couldn’t achieve more than 5k users.
It would help us if you could share the OS tuning parameters and cache sizes in Openfire. Though we’ve gone through this forum to get this info, somehow we are unable to shoot up above 5k.
This could help us verify our settings once again. Below are the existing configurations in our system.
Also the network is important.If you use the Internet, you can consider the route and firewall problem.The homeuse route can only support 5000 user max.
Thanks for your prompt response and time. Please confirm if Roster Creation was ALSO involved in your usecase.
We’ve made the tuning as mentioned above but still face the same issues.
We’ve used JMeter Bean Sampler which calls a method and does the following.
Open a WS(websocket) connection to OpenFire
Pass an IQ stanza for UserCreation
Close the WS connection.
We’ve written custom plugins in OpenFire to intercept the packet and create the User synchronously and create the Roster for the User asynchronously. We see there is a considerable delay in creating the Roster, which is too slow in Openfire. We’ve configured 25 DB Connections.
