[hydra-dev] Scalability

[John Todd]

On Jun 18, 2010, at 2:10 PM, Chris Tooley wrote:

> On Fri, Jun 18, 2010 at 3:59 PM, John Todd <jtodd at digium.com> wrote:
>>
>> [snip]
>> Well, I think it's close to being reasonable.  However, I'm uncertain
>> if "subscribers" is the right measure.  I'd say "channels" or "active
>> communications" or something a bit less oriented towards a commercial
>> relationship and more to a functional expectation.  A "subscriber" is
>> someone who has some unknown amount of idle time, and with new
>> versions of communications popping up that have unknown maximum busy
>> hour transactions (chat, video, smell-o-vision) we can't really base
>> the system on future unexpected user behaviors.  We perhaps may wish
>> to use instead a count of active communications paths...?
>>
> While I don't completely disagree with the "active communications
> paths" being the largest burden on the system, "subscribers" have a
> demonstrative impact on the performance of the system as a whole. In
> all likelihood the subscribe, "are you still there", "where are you
> at", and unsubscribe control communications for a subscriber will
> account for a large volume of traffic as a whole than active
> communications to/from that subscriber (except of course in cases like
> RTP). Thinking specifically of SMS or IM protocols the awareness of
> the endpoint can end up accounting for more traffic than the actual
> initiated communications.

I see your point, but I'd say that registrations or asynchronous  
messages then become something to count and that are not directly  
related to "subscriber" volumes.

For instance: I am a call center.  I have 10,000 seats.  I have a re- 
REGISTER interval of 30 seconds.  Do I want to copy the exact system  
that an ITSP has who sells to 10,000 subscribers at retirement  
communities and has a re-REGISTER interval of 3600 seconds?

These are things that we can't predict with any certainty, especially  
since we don't know what out-of-band requirements will be for future  
protocols.  So let's just base our number on the number of messages or  
volume of media packets...

The more I think about it, the less meaningful a "size" number  
becomes, so I'm not sure that a subscriber count or message volume or  
any other such concept is really useful other than saying "a whole lot".


>> This brings into question how asynchronous communications are  
>> counted,
>> and I'm not sure how to consider that.  Maybe our concept of
>> "channels" is based on the idea of 'communication packets flowing at
>> least once per second' or some measurement like that.  But I don't
>> want to fall too deep in that rathole when an 80/20 rule will work
>> quite well here (but I'm not sure that "subscribers" is an 80/20-
>> compatible number, which is why I comment here.)
>>
>> JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/