I know this is old but I'm adding this information for the next guy searching for this issue... This came to me from our Cisco team, who apparently received it from the BU @Cisco.
The main thing to consider from an IMP server perspective is the fan-out of presence to your buddies/watchers, and the cost of this in terms of resources on the server. In particular the SIP presence we consume primarily from CUCM phones which is particularly heavy traffic to process.
Let’s take the example below whereby a single Jabber user with 1000 users in their roster picks up their phone to make a call. Let’s assume each of these 1000 buddies has two devices each. Presence updates must be sent to each of these 2000 watchers. This is a very resource intensive operation for that single act for that single user. Now start multiplying that for all users on the system and multiply again for every status update per hour. The problem should become apparent pretty quickly.
For us to observe the thresholds of the prescribed IMP OVA’s, and meet the traffic profiles we have established as ‘typical’ for our customers, we have to either limit the number of users/devices on a box or limit the size of the roster. The sizes of the supported OVA’s e.g. 15K OVA, is already set in stone which will allow us to support 15K users/devices so that limits one option. We only have sufficient resources on the box to be able to support those 15K users if we observe our own requirements. Having a roster size of an average of 75 Presence contacts in your roster is one of these requirements. As Rory mentions below, it is documented as 100 but this is made of 75 presence contacts and 25 Non-presence contacts. The reality is that the non-presence contacts are little more than database padding.
That is not to say that a user with 1000 contacts wont work on IMP, but obviously every user cannot have 1000 buddies and several thousand watchers without there being a cost on the server. The recommendation is that for the 15k OVA example, there should be an average total of 75 presence contacts in your roster – regardless of whether they are in groups or p2p contacts. We know this will work and have tested to this and advertised this as a safe usage level. Having a handful of users with 1000 should not pose a problem as long as the average /user on the system remains around 75.
I think the observations Doys mentions below points to the fact that the cost is not linear. One could be forgiven for thinking that 12K logged in users with 75 presence contacts would be roughly equivalent to 6K logged in users with 150 presence contacts in terms of resources used on the IMP server. Unfortunately that is not the case and it is actually more costly to have those 6K users. The bigger you make the roster (and the higher you make the proportion of SIP traffic you have to process) the more it costs, and the less users you can support being logged in concurrently.
To put that in perspective, again using the 15K OVA example, if every user on the server had 1000 contacts in their roster, we would most likely only be able to support less than 1000 of these users being logged in at any given time observing our standard traffic profile.
I think the moral of the story here from an IMP perspective is that Presence processing costs a lot. SIP presence costs even more. Also, just because you can on Jabber, doesn’t mean you should.
