Assuming a standard usage rate of 10-15%, that's 2,400 concurrent users. If you divide that by 120, that's about 20 Asterisk systems. We're no where near that yet, and we only have three systems up right now. Gotta start somewhere!
-----Original Message-----
From: unplug [mailto:[EMAIL PROTECTED]
Sent: Tue 7/11/2006 7:23 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc:
Subject: Re: [asterisk-users] Server redundancy
I feel interested about you can support 16,000 users of your system.
As I have tested using sipp in a dual CPU Xeon with 2G Ram, the
maximum number of current call is about 160. In some forums, most of
ppl claim the maximum current call is about 100-200. What do you
expect the number of current call to handle in 16,000 users?
On 7/11/06, Douglas Garstang <[EMAIL PROTECTED]> wrote:
> > -----Original Message-----
> > From: RR [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 11, 2006 12:45 AM
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: Re: [asterisk-users] Server redundancy
> >
> >
> > Interesting points on both messages
> >
> > 1) as far as multiple asterisk servers talking to the same database
is
> > concerned, I will have to test this out. I know nothing about the
> > database side of things, and a newbie on asterisk and linux so I
have
> > no idea what and where the development of either of these are. From
> > your message it sounds like it's just how ARA is designed because I
> > doubt it's to do with the ODBC driver itself. This will cause me a
lot
> > of grief if you're right about this for multiple * servers to not be
> > able to access the same database for peer lookup.
> Be prepared for some grief then! :)
>
> >
> > 2) Clustering of DB isn't an issue, not for me at least. Haven't
> > tested this either but my DBs are clustered A/P providing a single
> > entity to the internal systems. Might further look into a local DNS
> > lookup to add to this. I believe it's possible to do this in the
MySQL
> > world with MySQL grid etc?
> >
> > 3) I don't believe frequent registration is that big of an issue for
> > the network load it generates. Most providers out there set devices
> > for a 30-40secs Reg. Refresh to support NAT'ed endpoints and the a
reg
> > refresh is hardly about 300-400Byte pkts (I think). The math doesn't
> > add up for a major load esp. if you've got a load balancing
mechanism
> > in front of your * boxes.
> OMG. 30-40seconds? That's insane. We're planning on provisioning
16,000 users on our system. With a registration period of 40s, that's an
average of over 400 registrations per second. Actually, it could be over 800
per second, as I think phones re-reregister at half their expirey period.
>
> >
> > 4) I don't know enough about DUNDi to get into this discussion but
> > DUNDi just lookup extensions? or it also have any part to play in
> > registrations? If they just do extension lookup, then If DUNDi is
> > implemented on an A/P pair of dedicated DUNDi lookup servers which
> > access a clustered database, then barring #1 being true, each *
server
> > accesses the same database and pool of registrations. If
registrations
> > are refreshed frequently enough, the contact info in the database
will
> > always be current and one server dying won't affect anything. At the
> > same time, they just consult the DUNDi lookup server for extension
> > lookups instead of asking the database directly.
> DUNDi can only lookup the extensions (ie phones) if they are
registered. If they aren't registered on any system in the DUNDi peering
arrangement, then DUNDi wouldn't return a path to their location... until the
phones re-reregister.
>
> >
> > 5) If you really want to improve on this, supplement your network
with
> > SER as proxies and have them deal with Registrations and
load-balance
> > feature requests to * servers etc. Once * has done whatever it needs
> > to do (e.g. provide PBX features, voicemail, conference, IVR etc.)
it
> > passes the call back to the Proxy to deal with the endpoints.
> Not as simple as it sounds. So, if the SER boxes handle
registrations, how do they propogate this information back to Asterisk? If you
don't propogate the information back to Asterisk, then you have to route all
dialling from Asterisk back to SER. This causes problems withn certain
applications like the Queue command, that as far as I know, can't work with
this. There's probably more too. You also have to keep call transfer and call
forward in mind. When transferring a call, if you pass the call from Asterisk
over to SER for some reason, it has to come back to the same Asterisk box to
handle the transfer, Asterisk will puke.
>
> >
> > All depends on your scope and budget. If you want to have a SP grade
> > service then you need to breakout your functions.
> >
> > I just hope #1 isn't true though. The only alternative then would be
> > to have /etc/asterisk reside on an NFS share or a CFS for all
servers
> > to read massively huge conf files if you're catering for large
number
> > of endpoints.
> >
> > Dunno if it helps anyone or I'm just shooting sh*t ;)
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
<<winmail.dat>>
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
