I'd say less than 1000. When you start breaking the 500-700 seat threshhold you start seeing where small performance enhancements make a big difference.
On Mon, Jun 20, 2011 at 3:47 PM, Nathaniel Watkins < [email protected]> wrote: > When we are dealing with ‘smaller’ vs. ‘larger’ – what types of > thresholds are we talking about.**** > > ** ** > > i.e. does smaller mean less than 100 endpoints or does smaller mean less > than 1000?**** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Michael Picher > *Sent:* Monday, June 20, 2011 12:22 PM > *To:* sipXecs developer discussions > > *Subject:* Re: [sipx-dev] Suggestion for DNS improvements within sipXecs** > ** > > ** ** > > Paul,**** > > ** ** > > I disagree with your assessment in (2). On smaller systems this may seem > insignificant but on larger systems the load here is real... even with a > caching dns setup (which is what is needed at a minimum anyway...).**** > > ** ** > > Mike**** > > On Mon, Jun 20, 2011 at 7:45 AM, <[email protected]> wrote:**** > > Wow, a lot of discussion on this topic, I think now is the time to give > this thread a new start. > Let's inventorize improvements and issues, create JIRA's for them and then > come up with solutions for them. > > Maybe I've got it (completely/partially) wrong, but this is my attempt to > summarize the thread. > A start, 1 to 4 are improvements IMHO, 5 to 7 are issues/JIRA's, should two > be created for 6 and 7? > > 1) Bind views > Bind Views are nice to implement branches, and if you want to use branches > then DNS views are almost mandatory. > We could even decide that they are mandatory, but I don't see what relation > they have with DNS problems in the sense of resource utilization/load. > So the whole views discussion should be part of the whole branch design. > 2) SipX issues a lot of queries > I think the load is not that high, but it's easy to make a linux box cache. > To create a self refreshing cache is nice, but it means reinventing the > wheel. The wheel will allow a higher topspeed, > but I think sticking to the tried and tested "wooden wheel" caching DNS is > a tremendous step forward. > 3) HA optimization > HA should be as fluent as possible. > Do we need to lower TTL's ( what does it bring, it would mean dynamic DNS > SRV records) > or rely on DNS to give a list of servers for each service and let the > clients/servers find an active box/service. > 4) DNS server failover (on linux level) > This can be optimized for faster failover > 5) SipX resolving unused services > SipX resolves tls records although tls is not used (already a JIRA: > http://track.sipfoundry.org/browse/XX-9639) > 6) SipX resolving records not listed in sipx-dns or/nor DNS advisor **** > > _sip._udp.rr.first.internal.epo.org **** > > is an example > 7) A record for domain needs to be there > According to Tony, I have an A record that I need (for XMPP :) so can't > confirm. > > etc etc > > > > [email protected] wrote on 17-06-2011 16:06:00: > > > From: > > > > "Geoff Van Brunt" <[email protected]> > > > > To: > > > > "sipXecs developer discussions" <[email protected]> > > > > Date: > > > > 17-06-2011 16:06 **** > > > > > Subject: > > > > Re: [sipx-dev] Suggestion for DNS improvements within sipXecs ** ** > > > > > Sent by: **** > > > > > [email protected] **** > > > **** > > > >You can always create a sub-domain (ie., voip.yourdata.domain) and > > then to a FWD lookup in your Windows server to the Linux >DNS... > > With domain aliases in the system you can add yourdata.domain if you > want to > > > > I agree, but for these users SipX needs to hand hold them. Many > > Windows DNS admins only know the basics and have no idea what a > > NAPTR record is (they are now available in 2008 R2). Having a sub > > domain managed by SIPX is not terribly difficult, but they generally > > have no clue how to set this up properly. MS has made DNS a no > > brainer for Active Directory domains which is both a good and bad > > thing. As mentioned in my early post a gui wizard would be ideal for > > getting them both educated to the choices available, and to setting > > up either one. > > _______________________________________________ > > sipx-dev mailing list > > [email protected] > > List Archive: **** > > http://list.sipfoundry.org/archive/sipx-dev/ > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/**** > > > > > -- > Michael Picher > eZuce > Director of Technical Services > O.978-296-1005 X2015 > M.207-956-0262 > @mpicher <http://twitter.com/mpicher> > www.ezuce.com**** > > ------------------------------ > This message and any files transmitted with it are intended only for the > individual(s) or entity named. If you are not the intended individual(s) or > entity named you are hereby notified that any disclosure, copying, > distribution or reliance upon its contents is strictly prohibited. If you > have received this in error, please notify the sender, delete the original, > and destroy all copies. Email transmissions cannot be guaranteed to be > secure or error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. Garrett County > Government therefore does not accept any liability for any errors or > omissions in the contents of this message, which arise as a result of email > transmission. > > > Garrett County Government, > 203 South Fourth Street, Courthouse, Oakland, Maryland 21550 > www.garrettcounty.org > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- Josh Patten eZuce Solutions Architect O.978-296-1005 X2050 M.979-574-5699
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
