dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
16765
share rss forum feed


derekm

join:2008-02-26
kudos:1
reply to derekm

Re: Google DNS versus ours

@TSIMarc:
An even easier solution, set the max-cache-ttl and max-ncache-ttl :

»www.zytrax.com/books/dns/ch7/hkp···ache-ttl

You can auto-expire your cache settings every 10 minutes - 1 hour.



TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28

1 edit

yeah but that doesn't lead to better performance.. you want records that are accurate to stay cached so their response is fast.. having to go query the auth dns server where the records are hosted is the part that takes the longest...

sometimes this is why larger dns servers may perform better since they have more queries cached by virtue of simply having more people use it... in that way they dont need to delay while it fetches the record, somebody else has already done that in some cases so to you it appears quicker. typically that's where people might argue that its better.

at our size now though I'd say that's fairly moot but to me that's the only real legitimate thing one could say.. the more users use our servers.. the less of an issue that is too..
--
Marc - CEO/TekSavvy


The Mongoose

join:2010-01-05
Toronto, ON

I caught this thread and decided to re-run namebench...a while back I was having some trouble and switched everything over to Google DNS. Today's test results:

Fastest: TekSavvy
2nd: UltraDNS (31% slower than TSI)
3rd: Primus (35% slower)

Other notables...OpenDNS was 37% slower, Google DNS was 48% slower.

I've switched back to TekSavvy's servers as a result, so far working fine.



HiVolt
Premium
join:2000-12-28
Toronto, ON
kudos:21
reply to TSI Marc

I'll switch back to the TSI servers and see how they perform now...


voxframe

join:2010-08-02
reply to TSI Gabe

Bench tested TSI servers today and they blow the list away. Wow!



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

We still have one server left to port over, so it's still technically not at it's best yet.


The Mongoose

join:2010-01-05
Toronto, ON

Do we get to find out which ones have been switched over so we can use the new ones? Or does it not matter (I can never fully wrap my head around DNS architecture)?



fluffybunny

@teksavvy.com
reply to TSI Marc

hmm..i get much worse performance with teksavvy DNS than with google :
using GRC nameserver benchmark :

206.248.142.222 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
- Cached Name | 0.000 | 0.016 | 0.081 | 0.021 | 100.0 |
- Uncached Name | 0.055 | 0.196 | 0.514 | 0.111 | 100.0 |
- DotCom Lookup | 0.077 | 0.163 | 0.272 | 0.052 | 98.0 |
------+-------+-------+-------+-------+-------+

vs

8.8.8.8 | Min | Avg | Max |Std.Dev|Reliab%|
----------------+-------+-------+-------+-------+-------+
+ Cached Name | 0.000 | 0.019 | 0.082 | 0.023 | 100.0 |
+ Uncached Name | 0.047 | 0.165 | 0.440 | 0.101 | 100.0 |
+ DotCom Lookup | 0.048 | 0.166 | 0.283 | 0.060 | 100.0 |
------+-------+-------+-------+-------+-------+



derekm

join:2008-02-26
kudos:1
reply to TSI Marc

said by TSI Marc:

yeah but that doesn't lead to better performance.. you want records that are accurate to stay cached so their response is fast.. having to go query the auth dns server where the records are hosted is the part that takes the longest...

Understood. It wasn't to suggest it would improve performance. It would improve accuracy though. It's a trade off.

If it's 100-500ms (500 would be terrible) every 10-60 minutes that get hit with the latency, I don't think it would even be noticeable, if you look at the average response time.

Also, the end-users computer would respect the TTL in its DNS cache, so it would only be new requests.

You could override this TTL cap for the top 1% of the queries, fairly easily, which would give you better performance for most sites, and better accuracy for the 'long tail'.

Just throwing some (unrequested) ideas out there.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28

yep. that's sort of how this is.. you kind of have to find a good balance based on the load that's on our servers.. there's no one size fits all kind of solution.

thanks for the input.
--
Marc - CEO/TekSavvy



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7
reply to fluffybunny

Much worse?

the Cached avg response time is lower for us and the std deviation is also lower.

The uncached is faster for Google by 9ms but still something seems odd with this report as the overall response times are much higher than what I would normally expect on a normal Internet Connection.

I don't know GRC that well...it runs on Windows it looks like
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

Alright, all servers are in production now

»tinyurl.com/9z899t3

Comparing our servers, 206.248.154.22 and 206.248.154.170 to OpenDNS and Google

And the clear winner is us
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

I should probably add that this test is being run from my house from a normal DSL connection, this isn't something that's being run right next to the server that would yield an unfair advantage.


jstory

join:2011-02-05
New Westminster, BC

Here on the we(s)t coast, Google's DNS is the clear winner.

dig teksavvy.com @8.8.8.8
shows a query time of 25 msec.

whereas,

dig teksavvy.com @206.248.142.222
shows a query time of 74 msec



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

That's because Vancouver has separate DNS servers.

You need to use 76.10.191.198 & 199



nitzguy
Premium
join:2002-07-11
Sudbury, ON
reply to TSI Gabe

Whats all this talk about 206.248.142.222?...

Is this a new DNS that's going to take over 206.248.154.22
and 206.248.154.170 ?

The graphs you indicate are talking about this DNS that isn't being propogated in the DHCP settings...

Perhaps that's why it runs better, lower load overall?...some special TSI only DNS? ....conspiracy theories abound.



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7

No that's just one of the DNS Servers that's behind the cluster of DNS servers...please stop testing against it because it was just for testing...


nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable

1 edit
reply to TSI Marc

said by mlord:

If there was a good way to let TSI know about it (specific site lookup failing), we'd probably do it.

There is - and we have told them. Many times. All we need is for someone from TSI to spend the time to diagnose. And yes, it does take time, as a good class of the problems with TSI's DNS servers are due to very slow DNS resolutions when the entry is not cached. If you test it when it is cached, it works great, but the initial cache is a disaster.

said by TSI Marc:

Like I mentioned, each time I hear somebody say our dns this or that.. I kind of scratch my head because I haven't seen a case where it was clearly our dns server at fault...

Look a bit harder:
»[Cable] Slow DNS resolution for site on Teksavvy
»Review of TekSavvy Cable by nbinont
»Teksavvy routing issues?

These are all DNS issues, despite the titles.

EDIT: I haven't tried the new servers yet.


hey_me

@teksavvy.com
reply to TSI Gabe

Not sure if this an issue with this upgrade or something else, but going to »www.telusmobility.com/ gives me
Access Denied by intermediary. Domain not recognized.

Doing a google search on that error seems to lead back to a DNS problem



AkFubar
Admittedly, A Teksavvy Fan

join:2005-02-28
Toronto CAN.
reply to TSI Gabe

works on my rig using tsi dns


highwire2007

join:2008-05-17
Nepean, ON
reply to TSI Gabe

I have rarely agreed about google/openDNS being better than TSI's DNS servers. Namebench consistently showed TSI being faster, with no time-outs, etc for me. Bell's were consistently the worst (very slow, lots of time-outs, etc.).

If this means performance gets even better, I'm happy!



TSI Gabe
Router of Packets
Premium,VIP
join:2007-01-03
Gatineau, QC
kudos:7
reply to nbinont

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

The second one...it's hard to tell, it's just a review that hasn't really been looked at to begin with.

The third one, the guy had just updated his DNS records on his own server, we forced a refresh for him as a courtesy.
--
TSI Gabe - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )



nitzguy
Premium
join:2002-07-11
Sudbury, ON
reply to TSI Gabe

said by TSI Gabe:

No that's just one of the DNS Servers that's behind the cluster of DNS servers...please stop testing against it because it was just for testing...

I never tested against it to begin with .

Was just curious....when I worked for a previous cable company, they had 4 DNS servers to autheticate, and it was always the 4th one that had the best results...presumably because it had the lowest load...so I set it as the primary manually....

Just was wondering if this was the case here... does .22 get more usage than .170 Gabe?


Jon111

@teksavvy.com
reply to TSI Gabe

Nice results on the DNS servers.

Where are they located? Are they in different sites etc for redundancy?


mlord

join:2006-11-05
Nepean, ON
kudos:13
Reviews:
·Start Communicat..
reply to TSI Gabe

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28

said by mlord:

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

Gabe appears to have looked that one up at the time and wrote this later in the thread:

»Re: [Cable] Slow DNS resolution for site on Teksavvy
--
Marc - CEO/TekSavvy


AkFubar
Admittedly, A Teksavvy Fan

join:2005-02-28
Toronto CAN.

Posted in the direct forum... no can read it...


nbinont

join:2011-03-13
kudos:2
Reviews:
·Start Communicat..
·TekSavvy Cable
reply to mlord

said by mlord:

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

Yep - my router using TSI's DNS servers. Though asking TSI's DNS servers directly with dig shows the same problem.


TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply to AkFubar

oh. hahaha, that's funny. I see says the blind man!?

looks like the first and the last are actually one and the same.

if we had problems with the dns servers.. we'd have thousands of calls... just look at the rogers outtage recently.. that's what happened.
--
Marc - CEO/TekSavvy



TSI Marc
Premium,VIP
join:2006-06-23
Chatham, ON
kudos:28
reply to nbinont

said by nbinont:

said by mlord:

said by TSI Gabe:

The first one, he's using 192.168.1.1 as his DNS server, not ours, hence why it's not working.

That's probably his router, which probably IS using TSI's server. Very standard setup, that.

Yep - my router using TSI's DNS servers. Though asking TSI's DNS servers directly with dig shows the same problem.

lets take a closer look see if we can figure out what's going on.
--
Marc - CEO/TekSavvy