I’m planning to start an IM for iOS and Android. I’ve secured VPS from some host with a dual-core 2.4Ghz Processor, 4GB RAM, 80GB Storage and like 5TB of Bandwidth.
I want to know if this is sufficient to use OpenFire and also anticipate around 25,000 concurrent users in a short time from launch?
With the DB, the scenario is as follows:
I’m using a Linux OS on my VPS. OpenFire has it’s embedded database, which if I use, would slow down the performance (read this on many forums here ) I have cPanel on my VPS, which also has MySQL installed.
So if I use the cPanel MySQL as my DB choice, would this be an external db scene (considering that both the cpanel and OF are installed on the same OS)? Also, is this a good thing to do and if somebody has used this method, can you please throw some light on the pros and cons of this and the number of concurrent users you’ve achieved.
This is a difficult question to answer as there isn’t a lot of publicly available performance data on the few Internet-facing Openfire servers I know about. Take a look over at Jabber/XMPP Server List for a pretty current list. Some of these sites have blogs that provide info about the hardware they’re running (for example, see https://alpha-labs.net/alpha-labs-net/hardware-current/). There is a relatively old doc on scaling, Openfire Requirements | Ignite Realtime , that still seems reasonable to me. The server cluster I run is intranet-only but is scaled for 10,000 users. Our current load is very low, with only about 200 concurrent users at any given time. It is a two server cluster, each 2 CPU x 8G RAM with a 50G data volume, using the Hazelcast plugin. We’re actually using very little of that disk, but RAM goes from around 1G to 2G on each server depending on load (G1GC is enabled to keep memory leaks under control). CPU utilization is usually low, but spikes at times. The MySQL db backend probably uses more resources than Openfire in the end. For anything over a couple of hundred users you should use a db backend rather than the embedded one. For what you’re proposing I don’t think you’re going to want to go live with anything less than a 4x8 (4 cores and 8G RAM). One way to distribute the load without going to a second app server and clustering would be to put your db on a different server, maybe a 2x4 on the same network segment. Some others here with more experience than me may have a different opinion, but if you really do get slammed with as may concurrent users as you’re expecting then you’ll also have to make sure your server’s disk and network I/O will be able to handle that kind of activity.